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

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

X-XSS-Protection は、他のブラウザーで採用されたために Microsoft が導入した HTTP ヘッダーです。これは、Cross-Site Scripting 攻撃が成功しないようにするものですが、図らずも安全な Web サイトを脆弱にしてしまうことになりました [1]。このため、この HTTP ヘッダーは以前のバージョンの Internet Explorer では使用しないでください。また、ヘッダーを 0 に設定して無効化する必要があります。

例 1: 次の例では Express アプリケーションで Helmet ミドルウェアを不適切に設定してすべてのバージョンの Internet Explorer でこれを有効にします。

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

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

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

例 1:

  Hidden hidden = new Hidden(element);

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

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

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

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

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

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

...
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 を使用する必要があります。

例 1: 次のコードでは、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 = (
    ...
    '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 オプションはすべての制限を解除し、リクエストごとにリファラー ヘッダーを送信します。

例 1: 次のコードでは、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 を変更できます。

次の場合、アプリケーションの認証および承認メカニズムは、HTTP 動詞の改ざんによってバイパスできます。
1) HTTP 動詞を一覧表示するセキュリティ コントロールを使用する。
2) セキュリティ コントロールが、リストされていない動詞のブロックに失敗する。
3) アプリケーションが、GET リクエストまたはその他の任意の HTTP 動詞に基づいて状態を更新する。



ほとんどの Java EE 実装では、設定で明示的にリストされていない HTTP メソッドが許可されています。たとえば、次のセキュリティ制約は、HTTP GET メソッドに適用されますが、他の HTTP 動詞には適用されません。

    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

HEAD のような動詞がこの設定の <http-method> タグで明示的に定義されていないため、GET または POST リクエストを HEAD リクエストに置き換えることで、管理機能を実行できてしまう場合があります。HEAD リクエストが管理機能を実行するには、条件 3 (アプリケーションは POST 以外の動詞に基づいてコマンドを実行する必要がある) が成立する必要があります。一部の Web サーバーまたはアプリケーション サーバーは、任意の非標準 HTTP 動詞を受け入れ、GET リクエストを受け取ったかのように応答します。こうなると、攻撃者が、リクエスト内の任意の動詞を使用して管理ページを表示できてしまいます。

たとえば、次に示すのは、典型的なクライアントの GET リクエストです。

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

HTTP 動詞改ざん攻撃では、攻撃者は GET を FOO のようなものに置き換えます

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

基本的に、この脆弱性は、拒否リスト (ユーザーに許可しないことを指定するポリシー) を作成しようとした結果です。拒否リストが意図した効果を達成することはめったにありません。

バッファー内の文字を検索する関数は、次のいずれかの状況で、指定されたバッファーの境界外にあるポインターを返すことがあります。

- ユーザーが、検索対象のバッファーの内容を制御している場合。

- ユーザーが、検索対象の値を制御している場合。

例 1: 次の短いプログラムは、rawmemchr() への呼び出しで、信頼できないコマンドライン引数を検索バッファーとして使用しています。

int main(int argc, char** argv) {
  char* ret = rawmemchr(argv[0], 'x');
  printf("%s\n", ret);
}

このプログラムは argv[0] のサブ文字列を出力するためのものですが、最終的に argv[0] より上位にあるメモリの一部を出力してしまうことがあります。

この問題は、文字配列に NULL ターミネータが含まれるとプログラマが信じ込んだ結果発生する String Termination Error に類似しています。

このクラスには、JCIP アノテーションパッケージのアノテーション Immutable が付けられています。しかし、このクラスの可変フィールドの 1 つには、コンストラクタおよびデストラクタの外側でコールされ変更されるメソッドが存在します。

例 1: 次の不変の final クラスのコードは、Set を private および final と宣言し、Set を変更するメソッドを誤って作成しています。

@Immutable
public final class ThreeStooges {
  private final Set stooges = new HashSet>();
  ...

  public void addStooge(String name) {
    stooges.add(name);
  }
  ...
}