W3C HTML 4.01 勧告(リンク先は和訳) [asahi-net.or.jp]に HTTP レスポンスヘッダは HTML 文書内の META 要素に優先すると書いてある。バグではないし仕様が腐っているわけでもない。キャッシュから読み込んだときに META 要素が優先されたらかえってやばいと思うけど。
by
Anonymous Coward
on 2005年12月22日 14時14分
(#853774)
この問題に関してはFirefoxのほうが危険な面もあります。 Internet Explorerは、UTF-16、UTF-7、ISO-2022-JPなどの「危険」なエンコーディング(1バイトの0～0x7f以外のものがASCIIと解釈されうるエンコーディング)はユーザーの指定では選択できないようになっています。 まあタレコミのようなUTF-7っぽいものをUTF-7と勝手に判別させる攻撃があるし親コメントのようなShift_JISに変えると発動するトラップも作れるのでIEなら安心なわけでは決してありませんが。
普通の文字化けと見分けは…… (スコア:2, すばらしい洞察)
エンコーディングを手動で指定するときはJavaScriptを切っておく、とかしかないのかな。
だとすると、エンコーディングを変更したときにJavaScriptが動くこと自体を脆弱性として取り扱える……かな?
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
# つか、おいらも気付かんかたーよこんな危険性 (^_^;;
むらちより/あい/をこめて。
オフトピ: Apache 1.3.12 文字化け問題 (スコア:2, 興味深い)
「Apache 1.3.12 文字化け問題 [asahi-net.or.jp]」より。
W3C HTML 4.01 勧告(リンク先は和訳) [asahi-net.or.jp]に HTTP レスポンスヘッダは HTML 文書内の META 要素に優先すると書いてある。バグではないし仕様が腐っているわけでもない。キャッシュから読み込んだときに META 要素が優先されたらかえってやばいと思うけど。
Re:オフトピ: Apache 1.3.12 文字化け問題 (スコア:0)
2回アクセスしたとき、1回目と2回目でサーバの応答のエンコーディングが異なっている場合、HTMLテキストはcacheから読んで、エンコーディングは2回目の応答ヘッダから読むという、そのW3C HTML 4.01勧告の方が危険な仕様ではないですかね。
Re:オフトピ: Apache 1.3.12 文字化け問題 (スコア:0)
Webメール (スコア:1, 興味深い)
海外のWebメールサービスを利用していると、日本語が文字化けして読めないことが往々にしてある（とゆか、素で読める方が少ないｗ）んで、無頓着にエンコーディングを変更してましたが、これからは気をつけたほうがいいのかな。
でも、往々にしてそういうサイトはJavaScriptを切ると動作しないので、対処の方法が……。orz
微妙にオフトピック気味ですが、UTF-7って複雑過ぎる規格ですよねー。
エスケープがあるから、UTF-8とは使い勝手が全く異なるし。
IETFでも非推奨扱いのようですから、早くこの世から消滅してほしいです。:-)
Re:Webメール (スコア:0)
IMAP5 とかまだ？
関連報道 (スコア:1, 参考になる)
被害者 (スコア:0, フレームのもと)
IEなんか使うからいけないんだよ。
Re:被害者 (スコア:3, 参考になる)
Re:被害者 (スコア:2, 参考になる)
Internet Explorerは、UTF-16、UTF-7、ISO-2022-JPなどの「危険」なエンコーディング(1バイトの0～0x7f以外のものがASCIIと解釈されうるエンコーディング)はユーザーの指定では選択できないようになっています。
まあタレコミのようなUTF-7っぽいものをUTF-7と勝手に判別させる攻撃があるし親コメントのようなShift_JISに変えると発動するトラップも作れるのでIEなら安心なわけでは決してありませんが。
Re:被害者 (スコア:2, 興味深い)
日本語に関してはそうですが、中国語のHZはそうではありません。選択できてしまいます。
Internet Explorerのこのメニュー構成が果たして、こういう問題を想定してのものかどうかについては疑問に感じます。
もしこの問題を予見していたのであれば、そもそも文字コードの自動検出からもこれらの文字コードを候補からは外しておくべきです。(単に開発者が異なっていて、連携がとれていないだけかもしれませんが、それはそれで問題。)
Mozilla関連プロダクトでもBugzilla-jpで意見を募っています [mozilla.gr.jp]。
予言成就 (スコア:1, 興味深い)
現実的な解としては「あり」だと思います。
予言 (スコア:0, おもしろおかしい)
↓
Re:予言 (スコア:0)
そんなに嫌なのかw
教唆 (スコア:0)
もちろん、自分で管理するコンテンツで、ですよね。
Re:教唆 (スコア:2, 参考になる)
.htaccess に書くのがとりあえず楽ですかね？
--
AddType "text/html; charset=EUC-JP" html
--
Re:教唆 (スコア:1)
個人的には AddType より AddDefaultCharset [apache.org] の方がきれいだと思っています。難点は text/* のコンテンツ全てに適用されてしまうことです。
ドキュメントごとに指定を変えられる AddCharset [apache.org] もあります。難点はファイル名にピリオドが増えことです。
動的コンテンツのほうが重要でした (スコア:1)
投稿した後で、静的コンテンツの場合は、自分の潔白を示すにはいいけど、XSS は無関係だと気付きました…
CGI を書くときにはこんな感じ。
次のように書いてある CGI が多くて
動きはするけどなんだかなあ、と思うことがあります。
Re:教唆 (スコア:1)
はぁ？
ファイルを特定したければ、
<Files></Files> 内に書けばいいじゃん。
ref.
http://httpd.apache.org/docs/2.0/mod/core.html#adddefaultcharset
Re:教唆 (スコア:0)
Re:教唆 (スコア:2)
Re:教唆 (スコア:1)
あっているように見えますが ...。
Japanese
EUC-JP,
SHIFT_JIS,
CP932,
ISO-2022-JP,
ISO-2022-JP-2,
ISO-2022-JP-1
Re:教唆 (スコア:2, 参考になる)
というところが気になるあなたは IANA での登録名 [iana.org]
でもチェックしてみて。
# mishimaは本田透先生を熱烈に応援しています
僕の場合常に (スコア:0)
Re:僕の場合常に (スコア:1)
http://httpd.apache.org/docs/2.0/mod/core.html
明示的に無効にするには、none じゃなくて off
一番危険なエンコーディングはISO-2022 (スコア:0, 余計なもの)
Re:ストーリのタイトルがわかりにくい (スコア:2, すばらしい洞察)
タレコミによれば2000年から知られていた問題だというのだから、Googleが対策を怠ったと考えれば、「GoogleにXSS脆弱性が見つかり修正」のタイトルが適切。
でもまだ知らない人が多いなら、そんなタイトルだと「Google固有の問題じゃないぞ」というコメントが付きまくるから、別のタイトルにした方がよさげ。
Re:ストーリのタイトルがわかりにくい (スコア:0)
見落としてる人おおそうだし。
Re:ストーリのタイトルがわかりにくい (スコア:1, すばらしい洞察)
Googleに～～ではGoogleの問題としか思わないでスルーされるでしょう。
Re:ストーリのタイトルがわかりにくい (スコア:1)
ここは/.ですから、今の方がよいかと思います。
# そろそろGoogleも無意味に叩かれるべき立場になってきたことには同意しますが。