アプリケーションが次の場合に Cross-Frame Scripting に対して脆弱になります。

1. iframe 内への追加をアプリケーション自体に許可する場合。
2. X-Frame-Options ヘッダーを介してフレーミング ポリシーを指定できない場合。
3. JavaScript ベースのフレーム バースティング ロジックなど、低品質の防御機能を使用する場合。

クロスフレーム スクリプトに対する脆弱性は、多くの場合、クリックジャッキング攻撃の土台となり、攻撃者はこれを利用し、クロスサイト リクエスト フォージェリ攻撃やフィッシング攻撃を実行できます。

HTML5 は、localStorage および sessionStorage マップを提供して、開発者がプログラムの値を保持できるようにしています。sessionStorage マップは、ページを起動するためのストレージを提供し、該当するページ インスタンスおよび直近のブラウザ セッションの期間だけ持続します。しかし、localStorage マップは、複数のページ インスタンスおよび複数のブラウザ インスタンスにわたってアクセス可能なストレージを提供します。この機能により、アプリケーションは、複数のブラウザタブやウィンドウで同じ情報を保持して利用できるようになります。

たとえば開発者は、ユーザーの元々の検索条件を保持しながら、ユーザーが複数のタブを開いて宿泊設備を比較できるように、複数のブラウザタブやインスタンスを旅行アプリケーションで使用したいと考える場合があります。従来型のストレージシナリオでは、ユーザーがあるタブで行った(そしてセッションまたは cookie に保存された)購入や決定が、別のタブにおける購入を妨げてしまう危険性があります。

ユーザーの値を複数のブラウザ タブ間で使用できる場合、開発者は、重要な情報を sessionStorage スコープと localStorage 間で移動しないように注意するよう必要があります。

例 1: 次の例では、クレジッド カードの CCV 情報がセッションに保存され、購入物についてカードで支払うことをユーザーがすでに承認していることが示されます。このブラウザー タブのコンテキストで購入しようとすると、必ずクレジッド カードの承認が求められます。CCV の再入力を回避するために、情報は sessionStorage オブジェクトに保存されます。しかし、開発者は、localStorage オブジェクト内にも情報を保存します。

...
try {
    sessionStorage.setItem("userCCV", currentCCV);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
}

...
...

var retrieveObject = sessionStorage.getItem("userCCV");
try {
    localStorage.setItem("userCCV",retrieveObject);
} catch (e) {
    if (e == QUOTA_EXCEEDED_ERR) {
        alert('Quota exceeded.');
    }
    ...

    var userCCV = localStorage.getItem("userCCV");
    ...
}
...

localStorage オブジェクトに情報を戻すことで、CCV 情報は他のブラウザ タブでも利用できるようになります。また、ブラウザを新たに呼び出した場合でも利用できるようになります。これは、アプリケーション論理の本来のワークフローを回避しています。

次の場合に、Cross-Site Request Forgery (CSRF) の脆弱性が発生します。
1.Web アプリケーションがセッションの cookie を使用する。
2.ユーザーの承諾を得てリクエストが作成されているかをどうかを検証せずに、この Web アプリケーションは HTTP リクエストを処理する。

例 1: 次の例では、Web アプリケーションは管理者にアカウントの新規作成を許可します。

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  rb.sendRequest(body, new NewAccountCallback(callback));

攻撃者は次のコードを含んだ悪意ある Web サイトをセットアップする可能性があります。

  RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
  body = addToPost(body, "attacker";
  body = addToPost(body, "haha");
  rb.sendRequest(body, new NewAccountCallback(callback));

example.com の管理者が、サイトでセッションを行っているときに、悪意あるページにアクセスすると、攻撃者にアカウントを作成してしまいますが、本人はそのことに気づきません。これが CSRF 攻撃です。アプリケーションには、リクエストの生成元を検証する方法がないために、この攻撃が可能となっています。リクエストはユーザーによって選択された正当なアクションにも、攻撃者が準備した不正なアクションにもなりえます。攻撃者は偽のリクエストを生成する Web ページを見ることができません。そのため、この攻撃方法は、アプリケーションの状態を変更するリクエストにのみ有効です。

cookie ではなく URL でセッション ID を渡すアプリケーションには CSRF の問題は存在しません。これは、攻撃者にとってセッション ID にアクセスすることやセッション ID を偽のリクエストの一部に追加することは不可能であるためです。

一部のフレームワークでは CSRF ナンスを自動的に含めることでアプリケーションの保護を支援します。この機能を無効化すると、アプリケーションにリスクが生じます。

例 2: Spring Security で保護されるこのアプリケーションでは、CSRF 対策を明示的に無効化します。

	<http auto-config="true">
        ...
        <csrf disabled="true"/>
	</http>

サイトがダウンロードをユーザーに提供できるようにする必要があるとき、ダウンロードを開くオプションを使用すれば、ブラウザーで実行される提供ファイルはすべて、現在のブラウザーでサイトと同じセキュリティ コンテンツで開けることになります。
攻撃者が、ダウンロードされたファイルを操作できる場合、ブラウザーで実行される HTML またはスクリプトを挿入して Cross-site Scripting 攻撃として動作させ、現在のセッションで情報を盗んだり、操作したりできます。

例 1: 次の例は、ブラウザーで実行されている、提供されたダウンロードに対する保護を明示的に無効化しています。

var express = require('express');
var app = express();
var helmet = require('helmet');

app.use(helmet({
    ieNoOpen: false
}));
...

クロスサイト WebSocket 乗っ取りは、正規のバックエンドサーバーとの WebSocket 接続を確立する悪意あるサイトにアクセスするようにユーザーが仕向けられた場合に発生します。WebSocket プロトコルへのアップグレードをサーバーに要求するために使用される最初の HTTP リクエストは、通常の HTTP リクエストです。そのため、ブラウザは、すべてのセッション cookie を含む、ターゲットドメインを指す任意の cookie を送信します。Origin ヘッダーの検証に失敗した場合、サーバーは、悪意あるサイトがユーザーに気づかれずにユーザーを偽装し、双方向 WebSocket 接続を確立することを許可します。

このアプリケーションは exclude 拒否リストを使用します。これでは保守管理が難しく、間違いが発生しやすくなります。開発者がフォームまたはフォームをバックアップする Model に新しいフィールドを追加するとき、exclude フィルターの更新を忘れると、機密フィールドを攻撃者にさらすことになります。攻撃者は悪意のあるデータを送信し、除外されていないフィールドにバインドできます。

例 1: 次のフォームは一部の User 属性を開示しますが、ユーザー id について拒否リストをチェックします。

from myapp.models import User
...
class UserForm(ModelForm):
  class Meta:
    model = User
    exclude = ['id']
...

User モデルが新しい role 属性で更新され、関連付けられている UserForm が更新されない場合、role 属性はフォームに表示されます。

File Based Cross Zone Scripting が発生するのは、次の条件のいずれかに一致した場合です。

1. アプリケーション内でスクリプトの実行を許可する可能性があるファイルがロードされた場合

2. ロードされたスクリプトの発生元が実行中のアプリケーションと同じであると見なされた場合

この両方の条件に一致すると、特に、第三者が情報の発生元がアプリケーションの境界内かどうかに基づいて信頼性を判定している場合、一連の攻撃が可能になります。

例 1: 次のコードは Android WebView を使用してファイルをローカルにロードします。

...
myWebView.loadUrl("file:///android_asset/www/index.html");
...

Example 1 の Android WebView レンダラーは、「file://」で開始する URL を使用する loadUrl() でロードされたものはすべて同じ発生元として扱います。

攻撃者がファイルからのロード時に File Based Cross-Zone Scripting の脆弱性を利用する場合、いくつかの典型的な方法があります。
- ローカル ファイルが攻撃者によって操作され、スクリプトがファイル内に挿入される。
これは、ファイルが存在する場所のファイル権限、またはファイルが保存されてロードされた場所の Race Condition に依存します。

- ファイルが外部リソースをコールアウトする。
これは、ロードされたファイルが外部リソースからスクリプトを取得する場合に発生します。

例 2: 次のコードは、外部リソースを参照して実行する JavaScript を決定しています。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

Example 2 では、セキュアではないプロトコルが使用されているため、悪意のある行為者による決定したスクリプトの改ざんが許可される可能性があります。または、他の攻撃が実行されてマシンが攻撃者のサイトに誘導される可能性があります。

- ロードされるファイルに Cross-Site Scripting の脆弱性が含まれている場合がある。
ロードされるファイルにコードの挿入が可能な場合、挿入されたコードがアプリケーションのコンテキストで実行できる可能性があります。このためには、JavaScript を挿入できる必要はなく、HTML を挿入できれば、改ざんや DoS (サービス妨害) 攻撃もできるようになります。

デフォルトでは、Flash アプリケーションには、同一生成元ポリシーが適用され、データ元が同じドメインである場合にのみ、2 つの SWF アプリケーションが互いのデータにアクセスできるようになります。Adobe Flash は、プログラミングにより、または、crossdomain.xml 設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。しかし、この設定を変更する場合には、注意が必要です。クロスドメインポリシーが過度に許容的であると、悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

例 1: 次の引用は、ワイルドカードを使用して、アプリケーションのやりとりを許可するドメインをプログラミングにより指定している例です。

   flash.system.Security.allowDomain("*");

* を allowDomain() への引数として使用すると、アプリケーションのデータが、任意のドメインにある他の SWF アプリケーションにアクセスできることになります。

デフォルトでは、Flash アプリケーションには、同一生成元ポリシーが適用され、データ元が同じドメインである場合にのみ、2 つの SWF アプリケーションが互いのデータにアクセスできるようになります。Adobe Flash は、プログラミングにより、または、crossdomain.xml 設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。Flash Player 9,0,124,0 以降、Adobe は Flash Player がドメイン間で送信できるカスタム ヘッダーを定義する機能も導入しました。ただし、これらの設定を定義するときには注意が必要です。過度に許容的なカスタム ヘッダー ポリシーを、過度に許容的なクロスドメイン ポリシーと一緒に適用すると、悪意のあるアプリケーションが任意のヘッダーをターゲット アプリケーションに送信できるようになります。その結果、さまざまな攻撃の対象となったり、受信したヘッダーの処理方法がわからない、アプリケーションの実行エラーが発生したりする可能性があります。

例 1: 次の設定では、ワイルドカードを使用して、Flash Player がドメイン間で送信可能なヘッダーを指定しています。

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

* を headers 属性の値として使用すると、任意のヘッダーがドメイン間で送信できてしまいます。

デフォルトでは、Flash アプリケーションには、同一生成元ポリシーが適用され、データ元が同じドメインである場合にのみ、2 つの SWF アプリケーションが互いのデータにアクセスできるようになります。Adobe Flash は、プログラミングにより、または、crossdomain.xml 設定ファイルの該当する設定によりこのポリシーを変更することを開発者に許可しています。しかし、この設定に影響を与えるユーザーを決定する場合には、注意が必要です。クロスドメインポリシーが過度に許容的であると、悪意のあるアプリケーションが不正な方法で攻撃対象のアプリケーションとやりとりし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。ポリシー制約の回避の脆弱性は次のように発生します。

1. 信頼されていないソースからデータがアプリケーションに入り込んだ場合。

2. このデータが、クロスドメインポリシー設定のロードまたは変更に使用されます。
例 1: 次のコードは、ロードされた SWF ファイルへのパラメーターの 1 つの値を URL として使用して、クロスドメインポリシーファイルをロードしています。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

例 2: 次のコードは、ロードされた SWF ファイルへのパラメーターの 1 つの値を使用して、信頼されるドメインのリストを定義しています。

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

Flash Player 7 から HTTP を介してロードされる SWF アプリケーションは、デフォルトで、HTTPS を介してロードされた SWF アプリケーションのデータにアクセスできなくなります。Adobe Flash は、プログラミングにより、または、crossdomain.xml 設定ファイルの該当する設定によりこの制約を変更することを開発者に許可しています。しかし、HTTP を介してロードされたアプリケーションは、中間者攻撃を受ける可能性があり、信頼するべきではないため、これらの設定を定義するときには、注意が必要です。

例 1: 次のコードは、allowInsecureDomain() をコールしています。これは、HTTP でロードされた SWF アプリケーションが HTTPS でロードされた SWF アプリケーションのデータにアクセスすることを禁止する制約を解除するものです。

   flash.system.Security.allowInsecureDomain("*");

一般的な開発手法として、デバッグやテストを目的として設計された、アプリケーションで実際に使用したり有効にしたりする予定のない「バック ドア」コードを追加することがあります。この種のデバッグ コードが誤ってアプリケーションに残された場合、アプリケーションで意図しない相互作用が発生する可能性があります。これらのバック ドア エントリ ポイントは、設計やテスト時に考慮されておらず、アプリケーションの想定される動作条件から外れるため、セキュリティ リスクが生じます。

GraphiQL は、GraphQL スキーマ イントロスペクション メカニズムを活用して、GraphQL API の開発とテスト用のグラフィカル インターフェイスを提供するブラウザー内ツールです。GraphiQL は、ユーザーが GraphQL スキーマを調べたり、GraphQL クエリを作成および実行したりするのに役立ちます。

GraphiQL を介して GraphQL スキーマのイントロスペクションを有効にすると、全体的なセキュリティにリスクが生じる可能性があるため、本番環境で GraphiQL へのアクセスを許可することはお勧めしません。攻撃者は GraphiQL とイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない可能性のある情報をリークする可能性があります。

例 1: 次のコードは、デフォルトで有効になっている GraphiQL を使用して GraphQL.js エンドポイントを初期化します。

app.use('/graphql', graphqlHTTP({
    schema
}));

GraphQL イントロスペクション機能を使用すると、誰でも GraphQL サーバーに現在のスキーマに関する情報を照会できます。利害関係者は、GraphQL イントロスペクション クエリを発行して、スキーマで使用可能な操作、データ型、フィールド、およびドキュメントの全体像を把握できます。

GraphQL イントロスペクションは、GraphQL API に関する情報の開発と共有のコンテキストで重要なユーティリティを提供します。イントロスペクションは、さまざまなツールとの統合を容易にする強力な GraphQL 機能です。たとえば、IDE はスキーマ イントロスペクションを活用して、GraphQL API を開発およびテストするための拡張機能を提供できます。

しかし、本番環境で誰でも GraphQL スキーマを照会できるようにすると、全体的なセキュリティにリスクが生じる可能性があります。攻撃者がイントロスペクションを使用して、GraphQL スキーマから実装の詳細を取得し、より的を絞った攻撃を実行できます。GraphQL スキーマは、内部で使用されるフィールド、説明、非推奨のメモなど、一般の使用を目的としていない可能性のある情報をリークする可能性があります。

例 1: 次のコードは、スキーマ イントロスペクションがデフォルトで有効になっている Hot Chocolate GraphQL エンドポイントを初期化します。

    services
        .AddGraphQLServer()
        .AddQueryType<Query>()
        .AddMutationType<Mutation>();
    

別の Web サイトにある実行可能なコンテンツを含めることは、危険です。自分のサイトのセキュリティを別のサイトのセキュリティに委ねることになります。

例 1: 次の script タグを考えてみます。

  <script src="http://www.example.com/js/fancyWidget.js"></script>

www.example.com 以外の Web サイトでこのタグが表示される場合、このサイトは www.example.com に依存し、正しい悪意のないコードが提供されます。攻撃者が www.example.com を乗っ取っている場合、fancyWidget.js の内容を改変して、サイトのセキュリティが侵害される場合があります。たとえば、fancyWidget.js にユーザーの機密情報を盗むコードが追加される可能性があります。

プログラマは、「ユーザーは非表示フィールドを見ることも、その内容を操作することもできない」という前提から、非表示フィールドの内容を信頼する傾向にあります。攻撃者はそのような想定に反して、非表示フィールドに書き込まれた値を調べ、その値を改ざんしたり不正なデータに置き換えたりします。

例 1:

  Hidden hidden = new Hidden(element);

重要な情報が非表示フィールドに保管されている場合、そのページ上の他の情報がキャッシュされるのと同じ方法で重要な情報がキャッシュされてしまいます。すると、ユーザーの知らない間に重要な情報がブラウザキャッシュに保存される可能性があります。

HTML5 の機能の 1 つに、クライアントサイド SQL データベースへのデータ格納機能があります。データベースの書き込みおよび読み取りを開始するときに必要となる主な情報は、データベース名です。したがって、データベースの名前をユーザーごとに異なる一意の文字列とすることが極めて重要です。データベースの名前を容易に推測できてしまう場合、他のユーザーなどの権限を持たない者が重要なデータを盗み出したり、データベースエントリを破壊したりできる可能性があります。
例 1: 次のコードでは、推測しやすいデータベース名が使用されています。

...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...

このコードは正常に実行されますが、データベース名を 'mydb' と推測できればだれでもアクセスできます。

コンテンツ セキュリティ ポリシー (CSP) は宣言型セキュリティ ヘッダーであり、開発者は Web ブラウザーでレンダリングされるときにサイトがコンテンツを読み込み、接続を開始するドメインを指示できます。Cross-Site Scripting、Clickjacking、Cross-Origin Access など、重大な脆弱性から守るために、入力検証とコードの許可リストのチェックに加え、さらにセキュリティの層を追加します。ただし、ヘッダーの設定が不適切であれば、このセキュリティの層は追加されません。このポリシーは 15 のディレクティブを利用して定義されます。そのうちの 8 つ、すなわち、script-src、img-src、object-src、style_src、font-src、media-src、frame-src、connect-src はリソース アクセスを制御します。

各ディレクティブが値としてソース一覧を受け取り、そのディレクティブで処理される機能にサイトがアクセスできるドメインを指定します。開発者はワイルドカードの * を使用し、全部または一部のソースを指示できます。いずれのディレクティブも必須ではありません。ブラウザは一覧にないディレクティブにすべてのソースを許可するか、任意の default-src ディレクティブからその値を導出します。また、このヘッダーの仕様は時間の経過とともに発展しています。Firefox の場合はバージョン 23 まで、IE の場合はバージョン 10 まで X-Content-Security-Policy として実装されていました。Chrome の場合はバージョン 25 まで X-Webkit-CSP として実装されていました。いずれの名前も廃止となり、新しい標準名の Content Security Policy に取って代わられました。ディレクティブの数、2 つの廃止となった代替名、1 つのヘッダーで複数回発生する同じヘッダーと繰り返しディレクティブの処理方法が指示される場合、開発者がこのヘッダーを間違って構成する可能性が高くなります。

次の間違い設定のシナリオについて考えてみましょう。

- unsafe-inline または unsafe-eval のディレクティブは CSP の目的を無効にします。
- script-src ディレクティブは設定されていますが、スクリプト nonce は設定されていません。
- frame-src は設定されていますが、sandbox は設定されていません。
- このヘッダーの複数のインスタンスが同じレスポンスで許可されます。開発チームとセキュリティ チームはいずれもヘッダーを設定することがありますが、一方が無効になった名前を使用することがあります。新しい名前 (コンテンツ セキュリティ ポリシー) のヘッダーがない場合、無効なヘッダーは受け取られますが、content-security-header 名のポリシーがある場合は無視されます。古いバージョンでは古い名前だけが認識されます。そのため、望ましいサポートを得る目的で、同一のポリシーと 3 つすべての名前をレスポンスに含めることが重要です。
- ヘッダーの同じインスタンス内であるディレクティブが繰り返される場合、後続のすべての発生が無視されます。

例 1: 次の django-csp 設定では、安全でないディレクティブ、unsafe-inline と unsafe-eval が使用され、インライン スクリプトとコード評価が許可されます。

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

コンテンツ セキュリティ ポリシー (CSP) は宣言型セキュリティ ヘッダーであり、開発者は Web ブラウザーでレンダリングされるときにサイトがコンテンツを読み込み、接続を開始するドメインを指示できます。Cross-Site Scripting、Clickjacking、Cross-Origin Access など、重大な脆弱性から守るために、入力検証とコードの許可リスト チェックに加え、さらにセキュリティの層を追加します。

Spring Security などのフレームワークは、デフォルトではコンテンツ セキュリティ ポリシー ヘッダーを追加しません。今回追加されたセキュリティの層によるメリットを得るためには、Web アプリケーションの作成者は、保護されたリソースの強制適用や監視をするセキュリティ ポリシーを宣言する必要があります。

Web サイトがフレームに追加されるのを許容することは、セキュリティ上の問題となります。たとえば、Clickjacking 脆弱性につながったり、望ましくないクロスフレーム通信を許容したりする可能性があります。

デフォルトでは、Spring Security などのフレームワークには、アプリケーションのフレーミングが必要かどうかをブラウザーに指示する X-Frame-Options ヘッダーが含まれます。このヘッダーが無効化されているか設定されていないと、クロスフレーム関連の脆弱性につながります。

例 1: 次のコードでは、Spring Security で保護されるアプリケーションで X-Frame-Options ヘッダーを無効化するよう設定します。

	<http auto-config="true">
        ...
        <headers>
            ...
            <frame-options disabled="true"/>
        </headers>
	</http>