アカウント名:
パスワード:
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)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
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」を明示する場合には別表現の方もちゃ
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
# つか、おいらも気付かんかたーよこんな危険性 (^_^;;
むらちより/あい/をこめて。