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);
  }
  ...
}

このクラスには、JCIP アノテーション パッケージのアノテーション Immutable が付けられています。final 以外のフィールドは、値が変更されるのを許可するため、クラスの不変性が侵害されます。

例 1: 次の不変クラスのコードは、フィールドを final と宣言するのではなく、誤って public に宣言しています。

@Immutable
public class ImmutableInteger {
public int value;

}

このクラスには、JCIP アノテーションパッケージのアノテーション Immutable が付けられています。可変タイプの公開フィールドが使用されていると、このクラスの外部にあるコードにより内容が変更されたり、このクラスの不変性が侵害されたりします。

例 1: 次の不変の final クラスのコードは、誤って Set を public および final と宣言しています。

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

キーボード拡張では、ユーザーが入力したすべてのキーボード操作を読み取ることができます。サードパーティのキーボードは通常、テキスト入力を容易にするため、または絵文字を追加するために使用され、ユーザーが入力した内容または処理のためにリモート サーバーに送信した内容を記録できます。キーロガーとして使用するために悪意のあるキーボードを配布し、ユーザーが入力したすべてのキーを読み取って、認証情報やクレジット カード番号などの機密データを盗むこともできます。

次の場合にコンパイラ最適化エラーが発生します。

1. 機密データがメモリに格納されている場合。

2. 機密データが、内容を上書きすることによってメモリから消し去られる場合。



3. ソースコードが最適化コンパイラを使用してコンパイルされている場合。最適化コンパイラは、そのメモリがそれ以降使用されないという理由で、内容を上書きする関数を無駄な格納域と識別して削除します。
例 1: 次のコードでは、ユーザーからパスワードを読み込み、パスワードを使用してバックエンドのメインフレームに接続してから、memset() を使用してパスワードをメモリから消し去ろうと試みています。

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

この例のコードは、逐語的に実行される場合は適切に動作しますが、コードが Microsoft Visual C++(R) .NET や GCC 3.x などの最適化コンパイラを使ってコンパイルされた場合、バッファ pwd が値の上書き後に使用されないため、memset() のコールは無駄な格納域として削除されます [2]。バッファ pwd には機密性の高い値が含まれるため、データがメモリに常駐したままになるとアプリケーションが攻撃に対して脆弱になる場合があります。攻撃者がメモリの適切な領域にアクセスできる場合、パスワードを回復してシステムを制御できる可能性があります。

攻撃者にシステムの機密事項がわからないように、メモリで操作されるパスワードや暗号鍵などの機密性が高いデータは上書きするのが普通です。しかし、最適化コンパイラを使用した場合、プログラムはソースコードのみが推奨する方法で常に動作するとは限りません。この例の場合、書き込み先のメモリがそれ以降使用されないため、明確にセキュリティ上の理由があるにも関わらず、コンパイラは memset() のコールを Dead Code と解釈しています。ここでの問題は、多くのコンパイラやプログラム言語では、効率の向上を目指すあまり、個別的なセキュリティ上の懸念材料が考慮に入れられていない点にあります。

攻撃者は通常、このタイプの脆弱性を悪用して、コアダンプまたはランタイムメカニズムを利用し、特定のアプリケーションが使用するメモリにアクセスして機密情報を回復します。機密情報にアクセスした攻撃者は比較的簡単にさらにシステムを悪用することができ、アプリケーションとやり取りする他のリソースが危険にさらされるおそれがあります。

配列チェックにおいて、不正なポインターの計算およびそのポインターが境界外にあるかどうかの判断が実行される場合、一部のコンパイラでは「プログラマが意図的に不正なポインターを作成することは決してない」という前提のもとに、このチェックが最適化によって削除されます。

例 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

buf + len という操作は 2^32 よりも大きいため、結果の値は buf よりも小さくなります。しかし、ポインタ上の算術オーバーフローは未定義の動作であるため、一部のコンパイラでは buf + len >= buf だと判断され、ラップ チェックが最適化で削除されます。そのような最適化が実行された結果、このブロックの後に続くコードが Buffer Overflow に対して脆弱にある可能性があります。

Django アプリケーションは、実運用環境に配置するように設計されていない static files アプリケーションの serve ビューを開示します。Django のマニュアルには次のように記載されています。

「static files ツールは、大部分において、実運用に静的ファイルを配置する作業を支援する目的で設計されています。これは多くの場合、ローカルで展開するときに大変な経費となる別個の専用静的ファイル サーバーを意味します。そのため、静的ファイル アプリに簡易ヘルパー ビューが付属します。これを利用し、開発にローカルにファイルを提供できます。

このビューは DEBUG が True の場合にのみ機能します。

そのため、このビューは著しく非効率的であり、おそらく安全ではありません。ローカルでの開発のみを意図しており、実運用では決して使用しないでください。」

機密情報が含まれる、または特権機能を提供するアプリケーション リソースは、一般的に危険にさらされる可能性が高くなります。調査の段階で、攻撃者はそのようなファイルやディレクトリを見つけようとします。そのようなリソースに予測可能な命名規則を利用すると、攻撃者はリソースの位置を簡単に発見できます。認証、管理タスク、個人情報の取り扱いなど、機密機能に関連するアプリケーション リソースはすべて、発見されないように十分に保護する必要があります。

例 1: 次の例では、admin アプリケーションが予測可能な URL に配置されます。

from django.conf.urls import patterns
from django.contrib import admin

admin.autodiscover()

urlpatterns = patterns('',
    ...
    url(r'^admin/', include(admin.site.urls)),
    ...

データの保存を担当するリソースは、アプリケーション機能を実装するリソースから離す必要があります。プログラマーは一時的なリソースまたはバックアップ リソースを作成するときに注意する必要があります。