Cross-Site Scripting: Inter-Component Communication (Cloud)

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

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

1.信頼できないソース経由で、クラウドでホストされる Web アプリケーションにデータが入り込んだ場合。コンポーネント間通信クラウドの XSS の場合、信頼できないソースは、クラウド ホストが提供する通信チャネルを経由した、クラウド アプリケーションの他のコンポーネントから受信するデータです。


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

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

例 1: 次の ASP.NET Web フォームは、Azure テーブル サービスで従業員を照会し、名前を出力します。

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>

EmployeeName は、次のように定義されるフォーム コントロールです。

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

例 2: 次の ASP.NET コードセグメントは、Example 1 と機能的には同じですが、すべてのフォーム要素をプログラミングによって実装しています。

protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;

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

例 3: 次の ASP.NET Web フォームは、従業員 ID 番号を HTTP リクエストから読み取り、ユーザーに対して表示します。

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Login および EmployeeID は、次のように定義されるフォーム コントロールです。

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

例 4: 次の ASP.NET コードセグメントは、Example 3 をプログラミングで実装する方法を示しています。

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

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

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

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

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

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

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

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