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

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

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

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

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

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 がアプリケーションのデータにアクセスできます。

HTML5 の機能の 1 つに、ドキュメント間メッセージがあります。この機能を使用すると、スクリプトが他のウィンドウにメッセージを送信できるようになります。対応する API では、ユーザーがターゲットウィンドウの生成元を指定することができます。しかし、ターゲットの生成元を指定する場合には、注意が必要です。過度に許可されたターゲットの生成元は、悪意のあるスクリプトが不正な方法で攻撃対象のウィンドウとやりとりし、偽装、データの盗み出し、リレー、およびその他の攻撃が実行される恐れがあります。

例 1: 次の例では、ワイルドカードを使用して、送信されるメッセージのターゲット生成元をプログラミングにより指定しています。

    WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
    webview.postWebMessage(message, Uri.parse("*"));

ターゲットの生成元の値として * を使用するということは、このスクリプトが生成元に関係なくウィンドウにメッセージを送信していることを示します。

ブラウザーのデフォルトでは、HTTPS から暗号化されていない HTTP リンクへ出されたリクエストについてはリファラー ヘッダーを送信しません。しかし、リクエストの宛先も HTTPS である場合は、生成元に関係なくヘッダーが送信されます。開発者が URL にある機密情報をそのままにしておくと、リファラー ヘッダー経由で第三者に開示される可能性があります。Referrer-Policy ヘッダーは、リファラー ヘッダーに関連するブラウザーの動作を制御するために導入されました。Unsafe-URL オプションはすべての制限を解除し、リクエストごとにリファラー ヘッダーを送信します。

例: 次のコードでは、Spring Security で保護されるアプリケーションでデフォルトの安全な Referrer-Policy を無効化するよう設定します。

	<http auto-config="true">
        ...
        <headers>
            ...
            <referrer-policy policy="unsafe-url"/>
        </headers>
	</http>

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

Content-Security-Policy-Report-Only ヘッダーにより、Web アプリケーションの作成者や管理者はセキュリティ ポリシーを強制適用するのではなく監視することができます。このヘッダーは通常、サイトのセキュリティ ポリシーを試用および/または開発する際に使用されます。ポリシーが有効であると判断された場合、代わりに Content-Security-Policy ヘッダー フィールドを使用すると強制適用できます。

例 1: 次のコードでは、コンテンツ セキュリティ ポリシーを Report-Only モードに設定します。

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

HPP (HTTP Parameter Pollution) 攻撃は、エンコードしたクエリ文字列区切り記号を既存のパラメーターに挿入することで構成されます。Web アプリケーションがユーザー入力の不要部分を適切に削除しない場合、悪意のあるユーザーがアプリケーションのロジックを悪用して、クライアント側またはサーバー側の攻撃を行う可能性があります。Web アプリケーションに追加のパラメーターを発行し、これらのパラメーターが既存のパラメーターと同じ名前を持っている場合、Web アプリケーションは以下のいずれかで反応します。

最初のパラメーターのデータのみ取得する
最後のパラメーターのデータのみ取得する
すべてのパラメーターからデータを取得し、それらを連結する


例：
- ASP.NET/IIS は、出現するすべてのパラメーターを使用します
- Apache Tomcat は、最初に出現したもののみを使用し、それ以外は無視します
- mod_perl/Apache は、値を値の配列に変換します

例 1: アプリケーションサーバーとアプリケーション自体のロジックに応じて、以下のリクエストが認証システムを混乱させ、攻撃者に他のユーザーの偽装を許す可能性があります。
http://www.example.com/login.php?name=alice&name=hacker

例 2: 次のコードは HTTP リクエストからの入力を使用して 2 つのハイパーリンクをレンダリングしています。

    ...
    String lang = request.getParameter("lang");
    GetMethod get = new GetMethod("http://www.example.com");
    get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
    get.execute();
    ...

URL: http://www.example.com?poll_id=4567
リンク 1: <a href="001">English<a>
リンク 2: <a href="002">Spanish<a>

プログラマは攻撃者が en&poll_id=1 のような lang を指定できる可能性を考慮しておらず、攻撃者が思いのままに poll_id を変更できます。