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

例:

  Hidden hidden = new Hidden(element);

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

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

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