ファイル権限操作のエラーが発生するのは、次の条件のいずれかに一致した場合です。

1. 攻撃者が、アクセス許可を変更する操作で使用されたパスをファイル システムで指定できる場合。

2. 攻撃者が、操作によって割り当てられたアクセス許可をファイル システムで指定できる場合。

例 1: 次のコードでは、システム プロパティからの入力を使用してデフォルトの権限マスクを設定しています。攻撃者がシステム プロパティを変更できる場合、プログラムを使用することによって、プログラムで操作されるファイルにアクセスすることが可能です。プログラムに Path Manipulation の脆弱性も存在している場合、攻撃者はこの脆弱性を利用してシステム上の任意のファイルにアクセスすることができます。

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

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

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

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

Hadoop Cluster Control エラーが発生するのは次の場合です。

- 信頼できないソースからデータがプログラムに入り込んだ。

- データが NameNode、DataNode、JobTraker などの、Hadoop クラスターのコアコンポーネントで使用され、Hadoop クラスターの状態が変更された。

Hadoop クラスターは適さない環境です。クラスターノードへの未許可のアクセスから保護するセキュリティが適切に設定されていない場合、攻撃によってインフラストラクチャの制御権が奪われます。それにより、Hadoop クラスターから提供されるデータが改ざんされる可能性があります。

例 1: 以下のコードは、Hadoop クラスター マスター マシンのコマンドラインから入力を受け取る、典型的なクライアントアプリケーションの Job サブミッションを示しています。

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

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

パスワードや暗号鍵のような機密性の高いデータが、メモリから削除されないために攻撃者の目に触れる可能性がある場合に Heap Inspection の脆弱性が発生します。

realloc() 関数は、割り当てられたメモリのブロックサイズを増やす際によく使用されます。この操作は多くの場合、古いメモリブロックの内容を新しい大きなブロックにコピーする操作を必要とします。この操作は、元のブロックの内容をそのまま保持してプログラムからアクセスできないようにするため、プログラムは機密性が高いデータをメモリから消し去ることができません。攻撃者が後でメモリダンプの内容をチェックできる場合、機密性が高いデータが攻撃者の目に触れる可能性があります。

例: 次のコードは、機密性の高いデータがあるバッファで realloc() をコールしています。

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

機密性が高いデータをメモリから消去しようと試みられていますが、realloc() が使用されているため、最初に plaintext_buffer に割り当てられたメモリにデータのコピーが残り、人目に触れる危険があります。

パスワードや暗号鍵のような機密性の高いデータが、メモリから削除されないために攻撃者の目に触れる可能性がある場合に Heap Inspection の脆弱性が発生します。

VirtualLock 関数は、メモリ内のページをロックしてディスクにページングされるのを防止するために使用されます。しかし、Windows 95/98/ME では、この関数はスタブとしてのみ実装されており効果がありません。

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

例:

  Hidden hidden = new Hidden(element);

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

X-XSS-Protection ヘッダーは通常、最新のブラウザーではデフォルトで有効になっています。このヘッダーの値が false (0) に設定されると、Cross-Site Scripting に対する保護が無効化されます。

このヘッダーは複数の場所に設定されている場合があります。また、このヘッダーは、設定の誤りと悪意のある改ざんの両方について検査する必要があります。

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

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>

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

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

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

HTML5 は、容易な入力フォームフィールドの検証を可能にする機能を提供します。入力フォームフィールドが必須であるかどうかを指定するには、required 属性を使用します。フィールドタイプを指定することで、入力はタイプと照合されます。さらに、カスタマイズ可能な pattern 属性を指定すれば、入力を正規表現と照合することもできます。ただし、form タグに novalidate 属性を追加し、submit 入力タグに formnovalidate 属性を追加した場合には、この検証方法は無効化されます。

例 1: 次のサンプルコードは、novalidate 属性を介してフォームの検証を無効にしています。

      <form action="demo_form.asp" novalidate="novalidate">
        E-mail: <input type="email" name="user_email" />
        <input type="submit" />
      </form>

例 2: 次のサンプルコードは、formnovalidate 属性を介してフォームの検証を無効にしています。

      <form action="demo_form.asp" >
        E-mail: <input type="email" name="user_email" />
        <input type="submit" formnovalidate="formnovalidate"/>
      </form>

検証が無効になっている HTML フォームは、ユーザーにとって使い勝手が悪いだけでなく、サーバーがさまざまなタイプの攻撃を受ける可能性があります。Cross-Site Scripting、Process Control や SQL Injection のような脆弱性の根本的な原因は入力の未検証です。

Spectre や Meltdown などの脆弱性に起因するサイドチャネル攻撃により、特定の Web ドキュメントのデータ プライバシーを強化することが重要になっています。Cross-Origin Opener Policy (COOP) は、サイドチャネル攻撃による機密情報の漏洩を防ぐために作成されました。具体的には、COOP は、ポップアップなどの他の外部ドキュメントに関して、ドキュメントのブラウジング コンテキスト グループの分離を強制できます。

例 1: 次のコードは、Django フレームワークにおける安全でない COOP 設定「unsafe-none」を示しています。これにより、サイドチャネル攻撃が発生したときに、外部ドキュメントがソース ドキュメントのブラウジング コンテキスト グループのプライベート データにアクセスできてしまう場合があります。

SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'

MIME スニッフィングとは、バイト ストリームのコンテンツを調べて、そのストリーム内のデータのファイル フォーマットを推定する手法です。

MIME スニッフィングが明示的に無効化されていないと、攻撃者が一部のブラウザーを操作して意図されない方法でデータが解釈されるようにすることがあるため、Cross-Site Scripting 攻撃が許容されてしまいます。ユーザーが制御可能なコンテンツを含む可能性がある各ページに対しては、HTTP ヘッダー X-Content-Type-Options: nosniff を使用する必要があります。

例: 次のコードでは、Spring Security で保護されるアプリケーションで MIME スニッフィング保護を無効化するよう設定します。

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

コンテンツ セキュリティ ポリシー (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_CLASSES = (
    ...
    '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>

コンテンツ セキュリティ ポリシー (CSP) は宣言型セキュリティ ヘッダーであり、開発者はブラウザー内で許可されるセキュリティ関連の動作 (コンテンツ取得元の場所の許可リストなど) を指定できます。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 はリソース アクセスを制御します。この 8 つのディレクティブでは、そのディレクティブで処理される機能にサイトがアクセスできるドメインを指定する値として、ソース一覧を受け取ります。開発者はワイルドカード * を使用するとソースの全部または一部を指示できます。ソース一覧キーワード、'unsafe-inline' や 'unsafe-eval' などを追加すると、スクリプト実行に対する制御の精度が高くなりますが、有害となる可能性があります。いずれのディレクティブも必須ではありません。ブラウザーは一覧にないディレクティブにもすべてのソースを許可するか、任意の default-src ディレクティブからその値を導出します。また、このヘッダーの仕様は時間の経過とともに発展しています。Firefox ではバージョン 23 まで、IE ではバージョン 10 まで、X-Content-Security-Policy として実装されていました。Chrome ではバージョン 25 まで X-Webkit-CSP として実装されていました。こうした名前はいずれも廃止となり、現在は標準名 Content Security Policyに取って代わられました。ディレクティブの数、廃止となった 2 つの代替名、同じヘッダーが複数回発生し 1 つのヘッダー内でディレクティブが繰り返される処理方法が指示される場合、開発者が誤ってこのヘッダーを設定する確率が高くなります。

例 1: 次のコードでは、過度に許容的で安全ではない default-src ディレクティブを設定します。

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

HTML5 以前の Web ブラウザーでは、同一生成元ポリシーが強制されます。このポリシーは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としている必要があります。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。Access-Control-Allow-Origin という新しい HTTP ヘッダーが定義されている場合、HTML5 では、JavaScript はドメイン間でデータにアクセスすることが可能です。生成元間の要求を使用してドメインにアクセスすることを許可する他のドメインを、Web サーバーはこのヘッダーを使用して定義します。しかし、このヘッダーを定義する場合には、注意が必要です。CORS ポリシーが過度に許容的であると、悪意のあるアプリケーションが不正に攻撃対象のサービスとやり取りし、偽装、データの盗み出し、リレーなどの攻撃が実行されるおそれがあるためです。

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

<websocket:handlers allowed-origins="*">
        <websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>

* を Access-Control-Allow-Origin ヘッダーの値として使用すると、任意のドメインで実行されている JavaScript がアプリケーションのデータにアクセスできます。