今回から3回にわたって,ratproxyが検出するぜい弱性のうち特徴的なものについて説明しましょう。前回挙げた(1)~(6)のぜい弱性のうち(1)Content-TypeやCharset指定の誤り,(2)write()などのJavaScript関数,(3)JavaScript Hijack/JSON Hijackの3種類を取り上げます。ここでは,ratproxyの挙動面だけではなく,ぜい弱性自体に関する技術的な内容についても説明をしますので,当面ratproxyを使用する予定がない方も参考にしていただければと思います。

 まず今回は,(1)のContent-Type指定の誤り(XSSの危険性)です。

 HTTPレスポンスには,通常「Content-Type: text/html; charset=UTF-8」といったレスポンス・ヘッダーが付けられます。このヘッダーは,「返信されるコンテンツがHTMLファイルであり,その文字コードはUTF-8である」ことを示しています。コンテンツがGIF形式の画像の場合なら,レスポンス・ヘッダーは「Content-Type: image/gif」となります。

 このContent-Type(Charsetを含む)ヘッダーの情報は,ブラウザがいかにコンテンツを解釈するべきかを伝えるための重要な情報です。これが適切に指定されていないと,攻撃者によってコンテンツの一部をコントロールされた場合に,XSSの攻撃が成立してしまう恐れがあります。以下では,どのようなケースでXSSにぜい弱になるのか,そしてどのような対策をとればよいのか,簡単に説明しましょう。

HTML以外のコンテンツを動的に生成するケース

 最近のWeb2.0的なWebアプリケーションでは,HTML以外の形式のコンテンツ,例えばJSON(JavaScript Object Notation),XMLなどのコンテンツを動的に生成するものがあります。気をつけなければいけないのは,こうしたコンテンツに付加するContent-Typeです。実際にWebアプリケーション検査の現場では,本来はHTML形式のコンテンツにつけるべき「text/html」というContent-Typeを,これらのコンテンツに誤って付けているケースを多く見かけます。

 Content-Typeが「text/html」になっていると,ブラウザはそのコンテンツをHTMLファイルとして解釈します。もし,攻撃者がコンテンツ内にscriptタグなどのHTML要素を挿入したら,ブラウザはそのコンテンツをHTMLだと解釈してしまうため,scriptタグ内に記述されたJavaScriptコードが実行されてしまいます。

 例えば,以下のようなJSON形式のコンテンツがあるとします。

{"data1" : "foobar1", "data2" : "<script>alert(111)</script>"}

このコンテンツには,攻撃者が仕込んだscriptタグが含まれています。レスポンスのContent-Typeが「text/html」になっていると,このJSONコンテンツにアクセスしたユーザー(被害者)のブラウザ上で,JavaScriptコードが実行されてしまいます。

 この問題の対策の基本は,コンテンツの中身に応じた適切なContent-Typeを付与することです。例えば,JSONをレスポンスする場合のContent-Typeは「application/json」,XMLをレスポンスする場合は「text/xml」もしくは「application/xml」を付けます。これにより,ブラウザがこれらのコンテンツを誤ってHTMLだと解釈しないようにします。

 ただ実際のところ,適切なContent-Typeを付けるだけでは対策として不十分な場合があり,それが事態を複雑にしています。例えば,Internet Explorer(IE)は「application/json」というContent-Typeが付けられたコンテンツを,場合によってはHTMLだと解釈してしまいます。

 一例を挙げると,「http://example.jp/jsonif」というURLの,JSONインタフェースがあったとします。この場合,IE6は「http://example.jp/jsonif?a.html」のように拡張子が「html」であるかのようなURLに細工してやると,Content-Typeが「application/json」であったとしても,JSONのレスポンスをHTMLと解釈します。

 本来このような問題はIE側で修正すべき問題なのですが,数年前から指摘されているにもかかわらず,現在のところ修正されていません。このため,コンテンツがHTMLだと誤解釈されないように適切なContent-Typeを付けるとともに,コンテンツが誤ってHTMLだと解釈された場合でも安全を保てるように,JSONデータ内の「<」「>」といったHTMLの特殊文字を「\u003C」「\u003E」といった形式にエスケープする対策が必要になります。