単純ではない、最新「クロスサイトスクリプティング」事情：HTML5時代の「新しいセキュリティ・エチケット」（2）（1/3 ページ）

HTML5の新しい要素、属性による、いままでとは異なるクロスサイトスクリプティングが登場しています。もう一度、XSSをおさらいしましょう。

[はせがわようすけ（ネットエージェント株式会社），＠IT]

連載目次

　皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。

　現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー（Same-Origin Policy）」に従ってリソースを保護しています。

　その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング（XSS）について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明します。

XSSの種類

　XSSは、大きく分けると「反射型XSS」「蓄積型XSS」「DOM Based XSS」の3種類があります。それぞれを説明します。

反射型XSS

　反射型のXSSとは、リクエスト内に含まれる攻撃者の用意したスクリプト（あるいはHTML断片）が、そのままレスポンスに含まれて発生するタイプのXSSです。

　典型的な例としては、検索ページでのXSSや、問い合わせフォームの確認画面でのXSSなどがあります。最近のWebブラウザーでは、マイクロソフトのInternet ExplorerのXSSフィルターのように、反射型XSSを緩和するための仕組みが組み込まれているものもあります（XSSフィルターの詳細については今後の連載でも解説する予定です）。

蓄積型XSS

　蓄積型XSS（あるいは持続型XSS）とは、攻撃者の用意したスクリプトがいったんWebサーバー内に格納され、特定のページを被害者が開いた場合にそのスクリプトが実行されてしまうタイプのXSSです。

　典型例としては、Webメールや掲示板でのXSSが挙げられます。蓄積型のXSSは、攻撃を仕掛けたタイミングと実際に被害が発生するタイミングに時間差があっても名称通り永続化して攻撃が成立するなど、反射型XSSに比べ被害が大きくなることが特徴です。

DOM Based XSS

　反射型XSS、蓄積型XSSの原因のほとんどは、Webアプリケーションにおいてサーバー上でHTMLを生成した際のエスケープ漏れですが、DOM Based XSSはサーバー上でのHTML生成そのものには問題はなく、その後ブラウザー上でHTMLを表示しJavaScriptが実行されたときに、JavaScript上のコードに脆弱性があるために発生するXSSです。

　例えば、document.write( document.referrer ); というJavaScriptコードでは、攻撃者は被害者をhttp://example.com/?<script>alert(document.domain);</script> のようなURLから攻撃対象サイトへアクセスさせることによって、攻撃用のJavaScriptコードをリファラー内に含め、被害者のブラウザー上で実行させることが可能となります。

HTML5によって増加するXSS

　HTML5では、多数の新しいHTML要素や属性が導入されていることに加え、Webアプリケーションとしての処理のブラウザー側へのシフトに伴い、JavaScriptコード量が増加したことなども相まって、従来の単純なXSS以外にも以下のようなXSSが発生、増加する傾向があります。

• HTML5の新しい要素、属性によるXSS
• DOM Based XSSの増加
• XHR Level 2によるリモートからのコード挿入によるXSS（連載第3回で紹介）
• XHRによってやり取りされるデータによるXSS（連載第3回で紹介）

　以下、順に解説していきます。

HTML5の新しい要素、属性によるXSS

　HTML5では多数の新しい要素や属性が導入され、ブラウザー上での表現力の向上や高機能化の支えとなっていることは周知の通りですが、攻撃者にとっても利用できる要素や属性が増加したということで、これまでとは異なった方法でXSSを発生させることができます。

　例えば、ユーザーが入力した文字列から<script>、<object>、<iframe>などのXSSに直結する要素やonmouseover、onerrorなどの「on」で始まるイベントハンドラーを指す属性、hrefなどのjavascriptスキームを代入できる属性といった、危険そうな文字列を探し出し、それらを全て削除するようなWebアプリケーションがあったとします。

　この方法は対策方法として間違っていますが、仮にこの方法によって全ての危険そうな文字列を探し出し、削除することでXSSを防ぐことに成功していたとします（実際のWebアプリケーションでは決してこの方法を採らないでください）。

　その場合であっても、HTML5によって導入された要素、属性によって攻撃者は簡単にXSSを発生させることができます。代表的なものとしてはbutton要素やinput要素（type="submit"の場合）におけるformaction属性があります。

<form>
    <button formaction="javascript:alert(0)">Click</button>
    <input type="submit" formaction="javascript:alert(1)">
</form>

　このように、ユーザーの入力から危険な要素や属性を検出して削除するといった方法では、新しく追加された要素や属性によって発生するXSSを防ぐことはできません。