[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Momonga-devel.ja:03553] Re: RFC: デフォルト文字エン コーディングの取扱いにつ いて



大垣です。

文字エンコーディングのデフォルトを決める、個人的に、一番目の目的は「パッケージとして
入れるアプリケーションがデフォルトの状態で正しく設定できるようにすること」です。
デフォルト文字エンコーディングを決めていないと不適切かつ安全でない設定で、一見動作
しているように見えてしまう場合があります。

デフォルト文字エンコーディングをUTF-8にした場合、SJISやEUC文字エンコーディングを使った
エスケープの回避や特殊文字の無効化などの攻撃が有効に動作しない場合もあり、セキュリティ
面でのメリットもあります。

ユーザが自前でインストールしたアプリもMoはUTF-8がデフォルトなのでUTF-8にしていれば
問題は発生しない、といったくらいので認識でアプリをインストールしても概ね大丈夫なく
らい安全性は実現できると思います。

どの文字エンコーディングに統一するか消去法で選ぶとUTF-8しか残りません。

文字エンコーディングを使用した具体的な攻撃例を上げるとすると以下のようなシナリオは
割と現実的だと思います。

1. postgresql-serverパッケージをインストール
2. 初回起動時に自動的にDBクラスタがASCIIをデフォルト文字エンコーディングとして
初期化される。(template0, tempalte1)
3. ユーザがCREATE DATABSASE等を文字エンコーディングオプションなしで実行。
(アプリのインストールマニュアルには文字エンコーディングオプション等は解説されていない
場合が多い。業務アプリならエンコーディングは指定していると思いますが。)
3. アプリケーションの設定でSJIS/EUCを文字エンコーディングに指定
(SET CLIENT ENCODING TOで設定、+アプリケーションが古いエスケープ方法を利用(\エスケープ))

上記のシナリオは、DB文字エンコーディングがASCII、SET CLIENT ENCODINGでエンコーディング指定
かつ古いエスケープ方法、とPostgreSQLの最悪の利用方法ですが上記のようなアプリケーションも
ないとは言えません。
# 「PHPサイバーテロの技法」(少なくとも初版)にはaddslashesによる
# エスケープが推奨されていました。また文字エンコーディングはDB API
# を利用して設定しなければなりませんがその解説もありませんでした。
# 私の本より売れているので結構上記のシナリオが適用できるかも。
# Railsの本でもSET CLEINT ENCODING/SET NAMESを利用している物も
# ありました。

DBサーバのデフォルトエンコーディングをUTF-8にしていたすると、EUCを利用した場合、
DBサーバ側の文字エンコーディングチェックにより不正なエンコーディングが検出され
攻撃できません。SJISの場合、結果が不正な文字エンコーディングになる場合、DBサーバ
側でチェックされ攻撃できません。正しい文字エンコーディングになってしまう場合、
(アプリケーションの入力パリデーションで文字エンコーディングの妥当性を検証していない
場合)前述のaddslashesによるエスケープ等は攻撃されます。
# 確か次のPostgreSQLでは\によるエスケープはサポートされないと
# 思います。現行の8.2からだったかも知れません。

このようにUTF-8にしているとデフォルトよりは良いといった状態になる場合もあります。
根本的な対処としてはアプリケーションの改修または安全に利用できる設定に変更する事が
必要であることは変わりありません。

--
Yasuo Ohgaki

y@xxxxxxxxxxxxxxxxx さんは書きました:
> 吉本です. 
> ircで突っ込みを受けた結果,少々私が誤解していることが判りました.
> 
> 大垣さん,変なメールを投げて申し訳ありませんでした.
> そして,突っ込みを下さったkourinさんありがとうございます.
> 
> 現状のパッケージ構成には以下の二つの問題
> 1) 現行のパッケージ構成では文字コードが統一されていないため
>    パッケージの組合わせによってはセキュリティ上の問題が起こり得る
> 2) 文字コードを統一するためにユーザが行う設定作業が煩雑
> があって,これを文字コードを統一することで解決するという点では,
> まったくもって大垣さんのおっしゃる通りだと思います.
> 
> 私が言いたかったことは,
> ユーザが独自にアプリケーションをインストールした場合に関しては
> 可能性の話になるので,上記の二つの問題とは別の三つ目の問題として
> 議論したほうが良いのではないか?ということです.
> --
> 吉本
> 
> At Sat, 01 Dec 2007 02:08:52 +0900,
> Hiromasa YOSHIMOTO wrote:
>> 吉本です.
>>
>> At Fri, 30 Nov 2007 07:31:03 +0900,
>> Yasuo Ohgaki wrote:
>>> 大垣です。
>>>
>>> MomongaLinuxにおけるデフォルト文字エンコーディングの取扱いについて提案です。
>>> ご意見をよろしくお願いいたします。
>> との事ですので,一点質問させてください.
>>
>> 可能性の話ではなく具体的例をあげて頂くと,
>> メリット・デメリットがより明確になり,議論しやすくなるかと思います.
>>
>> そこで質問ですが,具体的に問題となる例をあげて頂けませんか?
>> たとえばmomongaのhogehogeというパッケージにはfugafugaという問題があって,
>> その問題はhogehogeのデフォルトの文字コードをUTF-8にすると回避できる
>> という話であれば,
>> すくなくともhogehogeの文字コードはUTF-8にすべきだと思います.
>>
>> よろしくお願いします.
>> -- 
>> 吉本
>>
> 
>