アカウント名:
パスワード:
UTF-7 と ISO-2022(-JP) は 7 bits 伝送経路に対応した文字セットで、7 bits で表現できる文字コード (ASCII キャラクタ、および制御コード) のみによって構成されています。
これらの文字セットでは、8 bits 以上必要な文字を表現するため、特定の制御コードの出現を境に、文字コードをそのまま扱うモードと、エスケープされた表現によって文字コードを表現できるモードとを切り替えるように作られています。
エスケープされた表現を用いて、< や > を記述することができてしまう、ということですね。
Shift_JIS や EUC-JP 、UTF-8/16 などには、このような機能は無い (無くても十分なコードが表現できる) 文字セットなので、同様の脆弱性を心配する必要は無い、ということなんだと思います。
# 文字セットについてはこの辺 [euc.jp]とかの説明がわかりやすいかと。つか、走り書きゆえ、用語の厳密さとかはかなりいい加減っす m(_ _;)m
# つか、おいらも気付かんかたーよこんな危険性 (^_^;;
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
UTF-7エンコーディング (スコア:2, 参考になる)
Re:UTF-7エンコーディング (スコア:2, 興味深い)
> Set O (optional direct characters) consists of the following
(略
> Character ASCII & Unicode Value (decimal)
(略
> < 60
UTF-7においては文字「<」をバイト値「60」として表現するのは「optional」。つまり、バイト値「60」ではない表現形式もあって、そっちの場合は「<」に変換されないということか。
今回はcharsetが明示されていなかったことが問題でしたが、「charset=UTF-7」を明示する場合には別表現の方もちゃんと扱わないとまずいですね。
タレコミでは、
> たとえばISO-2022-JPでも同様のことが起こり得る。
とのことなのでISO-2022-JPの場合にもバイト値「60」以外の表現形式があるということと思われるが、
Shift_JIS,EUC-JP,UTF-8では大丈夫なのでしょうか。
charsetを指定することは大前提として、自分で指定したcharsetにおいて文字「<」が、どういう形で表現されうるか把握していないとハマルと思うねんけど。
Re:UTF-7エンコーディング (スコア:3, 参考になる)
<html>
<head>
aaa<script>/*bbb*/function msg(){alert('xss');}</script>
</head>
<body>
<button onclick="javascript:msg()">abc</button>
</body>
</html>
というファイルを作り、aaaをESC $ B、bbbをESC ( Bとバイナリエディタで置き換えると、<script>/*の部分が「首竰蜷(文字化け)(文字化け)」という文字列になります。
この文字列をサーバーがISO-2022-JPとして扱うと「首」に含まれる"<"はエスケープされませんが、クライアントがこれをEUC-JPとして扱うと「首」の部分は"<s"として扱われてしまいます。実際Firefox1.07では文字コードをEUC-JPなどとメニューから指定するとscript要素が有効になりました。
あと、試してませんが、EUC-JPやShift_JISで2バイト目を<にした文字を入れて、それをISO-2022-JPとして解釈させると<として扱われる、というのもあるかもしれません。
これの対策としては、サーバー側で、出力するエンコーディングにおいて0x3Cなどを含む文字を出力するときは数値参照に変換する、というのが考えられます。
Re:UTF-7エンコーディング (スコア:0)
Re:UTF-7エンコーディング (スコア:3, 興味深い)
UTF-7 と ISO-2022(-JP) は 7 bits 伝送経路に対応した文字セットで、7 bits で表現できる文字コード (ASCII キャラクタ、および制御コード) のみによって構成されています。
これらの文字セットでは、8 bits 以上必要な文字を表現するため、特定の制御コードの出現を境に、文字コードをそのまま扱うモードと、エスケープされた表現によって文字コードを表現できるモードとを切り替えるように作られています。
エスケープされた表現を用いて、< や > を記述することができてしまう、ということですね。
Shift_JIS や EUC-JP 、UTF-8/16 などには、このような機能は無い (無くても十分なコードが表現できる) 文字セットなので、同様の脆弱性を心配する必要は無い、ということなんだと思います。
# 文字セットについてはこの辺 [euc.jp]とかの説明がわかりやすいかと。つか、走り書きゆえ、用語の厳密さとかはかなりいい加減っす m(_ _;)m
# つか、おいらも気付かんかたーよこんな危険性 (^_^;;
むらちより/あい/をこめて。