デフォルトでは、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 を介してロードされたアプリケーションは、中間者攻撃を受ける可能性があり、信頼するべきではないため、これらの設定を定義するときには、注意が必要です。

例: 次のコードは、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 サイトにある実行可能なコンテンツを含めることは、危険です。自分のサイトのセキュリティを別のサイトのセキュリティに委ねることになります。

例: 次の 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 にユーザーの機密情報を盗むコードが追加される可能性があります。