Cross-Site Scripting: AI

未検証のデータを Web ブラウザに送信すると、結果としてブラウザで悪意のあるコードが実行される可能性があります。

次の場合に、Cross-Site Scripting (XSS) の脆弱性が発生します。

1.信頼できないソース経由でデータが Web アプリケーションに入り込んだ場合。リフレクト XSS の場合、信頼できないソースは Web リクエストであるのが一般的です。一方、持続型 XSS (別名: ストアド XSS) の場合はデータベースなどのバックエンドデータストアであるのが一般的です。


2.未検証で Web ユーザーへ送信される動的コンテンツにデータが含まれている場合。

Web ブラウザーへ送信される悪意あるコンテンツは多くの場合 JavaScript セグメントの形式になっていますが、HTML や Flash など、ブラウザーで実行される何らかのタイプのコードが含まれることもあります。XSS に基づく攻撃の種類はほぼ無限にあります。一般的には、cookie などの個人情報やその他のセッション情報を攻撃者に送信したり、攻撃者の制御下にある Web コンテンツに被害者をリダイレクトしたり、脆弱性のあるサイトを装ってユーザーのマシン上で悪意ある操作を実行したりします。

例 1: 次の JSP コード セグメントは従業員 ID eid を HTTP リクエストから読み取ってユーザーに表示します。

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

この例のコードは、eid に標準の英数字テキストだけが含まれている場合に正しく動作します。eid の値にメタ文字またはソース コードが含まれていると、Web ブラウザーが HTTP レスポンスを表示する際にコードが実行されます。

最初は、たいした脆弱性ではないと思うかもしれません。自分のコンピューター上で悪意あるコードが実行される原因となる URL を自ら入力する人などいないと考えがちです。実際に危険なのは、攻撃者が悪意ある URL を作成し、電子メールやソーシャルエンジニアリングのトリックを利用してその URL へのリンクをクリックさせるよう誘い込むことです。リンクをクリックすると、脆弱性を持つ Web アプリケーションを通して悪意あるコンテンツが被害者のコンピュータに影響を与えますが、本人はそのことに気づきません。脆弱性のある Web アプリケーションを悪用するこの仕組みは、リフレクト XSS と呼ばれています。

例 2: 次の JSP コードセグメントは特定の ID の従業員をデータベースでクエリし、対応する従業員の名前を出力します。

<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
   rs.next();
   String name = rs.getString("name");
}
%>

Employee Name: <%= name %>

Example 1 に示すように、name の値の動作が適切であればこのコードは正しく動作しますが、そうでない場合は悪用を阻止できません。この場合も、このコードはあまり危険がないように見えます。name の値はデータベースから読み込まれており、データベースのコンテンツはアプリケーションによって管理されているように見えるからです。ただし、name の値がユーザーの入力したデータに由来する場合は、データベースが悪意あるコンテンツの侵入路になることがあります。データベースに格納されている全データについて入力を適切に検証しない限り、ユーザーの Web ブラウザで攻撃者が悪意あるコマンドを実行する可能性があります。持続型 (ストアド) XSS と呼ばれるこのタイプの悪用は特に危険です。データ ストアを原因とする不正のために脅威を認識しにくく、攻撃にさらされるユーザーが増える可能性が高まるためです。XSS は、ビジターにゲストブックを提供している Web サイトで、次のような形で始まります。攻撃者がゲストブックのエントリに JavaScript を含めると、それ以降にゲストブックページを訪れたすべてのビジターが悪意あるコードを実行します。

一部には、モバイル環境では Cross-Site Scripting のような古典的な脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 3: 次のコードでは、Android の WebView で JavaScript を有効にして (デフォルトでは JavaScript は無効)、Android インテントから受け取った値に基づいてページをロードできます。

...
	WebView webview = (WebView) findViewById(R.id.webview);
  	webview.getSettings().setJavaScriptEnabled(true);
        String url = this.getIntent().getExtras().getString("url");
        webview.loadUrl(url);
...

url の値が javascript: から始まる場合、それに続く JavaScript コードが WebView 内の Web ページのコンテキストから実行されます。

これらの例からわかるように、XSS の脆弱性は、HTTP レスポンスに未検証のデータを入れるコードにより引き起こされます。XSS 攻撃が被害をもたらす可能性のある手段は 3 つあります。

- Example 1 に示すように、データが HTTP リクエストから直接読み込まれ、HTTP レスポンスに反映される場合。リフレクト XSS の悪用が発生するのは、攻撃者によりユーザーが脆弱性のある Web アプリケーションに危険な内容を入力させられてしまい、それがユーザーに送り返されて Web ブラウザにより実行される場合です。悪意ある内容を送りつけるために最もよく利用される仕組みは、公開投稿された URL や、電子メールで直接送信される URL のパラメーターに、悪意ある内容を含めるやり方です。この方法で作成された URL は多くのフィッシング方式の中核となっており、この方法で攻撃者は脆弱性のあるサイトの URL に誘い込みます。攻撃者の悪意あるコンテンツがユーザーに戻されてサイトで反映されると、そのコンテンツが実行され、セッション情報を含む可能性のある cookie などの個人情報をユーザーのマシンから攻撃者へ送信するといった悪辣な操作が実行されます。

- Example 2 に示すように、アプリケーションがデータベースなど信頼されているデータストアに危険なデータを格納する場合。それ以降、危険なデータがアプリケーションの読み込みに伴って戻され、動的コンテンツに含まれます。持続型 XSS の悪用が発生するのは、攻撃者が危険な内容をデータストアに挿入し、それが後で動的コンテンツに読み込まれる場合です。攻撃者の観点から見た場合、悪意ある内容の挿入に最適なのは、多数のユーザーまたは特定の対象ユーザーに対して表示される領域です。対象ユーザーは通常、アプリケーションに対する高い権限を持っているか、攻撃者にとって価値の高い機密データを操作します。こうしたユーザーが悪意ある内容を実行させられた場合、攻撃者はユーザーになりすまして権限の必要な操作を実行したり、ユーザーが所有する機密データにアクセスしたりできる可能性があります。

Example 3 に示したように、アプリケーション外のソースで危険なデータがデータベースやその他のデータストアに格納され、その危険なデータが信頼されているデータとしてアプリケーションに読み込まれ、動的コンテンツに含まれる場合。

最新の Web フレームワークの多くが、ユーザー入力を検証するためのメカニズム (Struts および Struts 2 を含む) を提供しています。検証されていない入力ソースの問題を正確に反映させるために、Fortify セキュア コーディング ルールパックは、フレームワーク検証メカニズムが使用されている場合には、その証拠を示し、悪用の可能性を低く見積もり、Fortify Static Code Analyzer により報告される問題の優先度を動的に変更します。この機能は、状況依存ランキングと呼ばれます。Fortify ユーザーがさらに監査プロセスを効果的に進めることができるように、Fortify Software Security Research グループでは、入力ソースに適用される検証メカニズムを基準としたフォルダに問題をグループ化する Data Validation (データ検証) プロジェクト テンプレートのフォルダを用意しています。