HTTPセキュア・ヘッダーの構成

XSS攻撃を軽減するためのヘッダー

クロスサイト・スクリプティング(XSS)攻撃は、攻撃者がWebアプリケーションを介して、ブラウザ側のスクリプトの形式で悪意のあるコードを別のエンド・ユーザーに送信するときに発生します。Webアプリケーションの障害により、XSS攻撃は成功し、この障害は、Webアプリケーションがユーザーの入力を検証またはエンコードせずに使用する場合は常に発生する可能性があります。

たとえば、攻撃者はXSSを使用して、悪意のあるスクリプトをユーザーに送信することがあります。この状況に気付かずに、エンド・ユーザーのブラウザは、スクリプトが信頼できるソースから来たものであると想定してスクリプトを実行し、ブラウザに保持されてそのサイトで使用されるCookieやセッション・トークン、その他の機密情報に悪意のあるスクリプトがアクセスするのを許可する可能性があります。

XSS攻撃を軽減するためのヘッダーには、次のものがあります:

コンテンツ・セキュリティ・ポリシー

コンテンツ・セキュリティ・ポリシー・ヘッダーを使用すると、従業員のかわりにリクエスト可能なリソースを開発者が制御できるので、コンテンツ・インジェクションのリスクが軽減されます。

コンテンツ・セキュリティ・ポリシーとは、Webアプリケーションのクライアント側リソース用にJavaScript、CSS、イメージなどのソース・ホワイトリストを作成できる、ブラウザ側のメカニズムです。コンテンツ・セキュリティ・ポリシーは、そのようなソースからのリソースのみを実行またはレンダリングするように、特別なHTTPヘッダーを使用してブラウザに指示します。

Webサーバーは、エンド・ユーザーのWebアプリケーションがスタイルシートやイメージなどをロードできるドメインのリストを把握していないため、コンテンツ・セキュリティ・ポリシーを実装するのは不可能です。Webサーバーは、アプリケーションがプラグインやメディアなどを使用するかどうかや、これらをロードできるかどうかも把握していません。

オラクル社では、コンテンツ・セキュリティ・ポリシー・ヘッダーを使用して、アプリケーション特性に基づくポリシーを定義および実装することをお薦めしています。

コンテンツ・セキュリティ・ポリシー・ルールの使用例を次に示します:

例: ルール1

Content-Security-Policy: default-src 'self'

これは制限的なルールであり、次のようなアプリケーションで機能します:

すべてのリソースが、指定したページの同じドメインでホストされます。
スクリプトおよびスタイル・リソースに対するインラインまたは評価がありません。

例: ルール2

Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';

このポリシーの内容:

オブジェクト、フレーム、メディアなどのリソースのロードを許可しません。
同じ起点からのイメージ、スクリプト、AJAXおよびCSSを許可します。

例: ルール3

Content-Security-Policy: frame-ancestors self;

X-XSS-Protection

ノート:

X-XSS-Protectionヘッダーは、最新のブラウザでは非推奨となっており、その使用によってクライアント側で追加のセキュリティの問題が発生する可能性があります。そのため、ヘッダーをX-XSS-Protection: 0に設定してXSS Auditorを無効にし、レスポンスを処理するブラウザのデフォルト動作を許可しないようにすることをお薦めします。かわりにContent-Security-Policyを使用します。「コンテンツ・セキュリティ・ポリシー」を参照してください。

X-XSS-Protectionヘッダーは、特定のWebサイトのXSSフィルタをユーザーが無効にしている場合に、再度有効にします。セキュリティのベスト・プラクティスとして、すべてのHTTPレスポンスにX-XSS-Protectionヘッダーを含めることをお薦めします。

これにより、反射型XSS攻撃のブラウザ検出が可能になります。根底にある反射型XSS脆弱性は、基礎となるアプリケーションで引き続き修正する必要があります。ブラウザがXSSを検出してブロックしていても、そのアプリケーションにXSS脆弱性があるわけではありません。場合によっては、このヘッダーが正当なレスポンスをブロックすることがあります。たとえば、javascriptプログラミングについて説明しているメッセージ・ボードなどです。

表3-1に、X-XSS-Protectionヘッダーの値を示します。

表3-1 ヘッダー値と説明

値	説明
`0`	フィルタが無効になります。
`1`	フィルタが有効になります。クロスサイト・スクリプティング攻撃が検出されると、ブラウザはページをサニタイズして攻撃を阻止します。
`1; mode=block`	フィルタが有効になります。ブラウザはページのレンダリングを防止します。
`1; report=http://<YOURDOMAIN>/<your_report_URI>`	フィルタが有効になります。ブラウザはページをサニタイズして侵害をレポートします。

クロスサイト・スクリプティング(XSS)攻撃を軽減するために、次の構成変更を行うことをお薦めします:

Fusion Middleware Controlの「サーバーの詳細構成」ページまたはテキスト・エディタを使用して、httpd.confファイルを開きます。

LoadModuleセクションの後に、次のヘッダー構成を追加します:

<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>

ノート:

ヘッダーを設定しても、これらの攻撃が防止される保証はありません。他のベスト・プラクティスも考慮してください。

HttpOnly

HttpOnlyは、Set-Cookie HTTPレスポンス・ヘッダーに含まれる追加フラグで、クライアント側のスクリプトが保護されたCookieにアクセスするリスクを軽減するのに役立ちます。

HttpOnlyフラグがHTTPレスポンス・ヘッダーに含まれている場合、クライアント側のスクリプトを介してCookieにアクセスすることはできません(ブラウザがこのフラグをサポートしている場合)。その結果、クロスサイト・スクリプティング(XSS)の欠陥が存在し、ユーザーがこの欠陥を悪用するリンクに誤ってアクセスした場合でも、ブラウザから第三者にCookieが公開されることはありません。

サンプル構成:

<IfModule mod_headers.c>
 Header edit Set-Cookie ^(?!IGNOREME=).*$ $0;HttpOnly;secure
</IfModule>

場合によっては、Cookieをjavascriptで使用できるようにすることが不可欠な場合があります。前述の構成例は、特定のCookieにHttpOnlyフラグを設定しないように指定するメカニズムを提供します。特定のCookieがHttpOnly属性の候補でない場合、文字列IGNOREMEを前述の構成内のCookie名に置き換えます。

HttpOnlyフラグがMYCOOKIE1というレスポンスCookieに追加されないようにするには、次のコマンドを実行して、IGNOREMEをMYCOOKIE1に置き換えます:

Header edit Set-Cookie ^(?!MYCOOKIE1).*$ $0;HttpOnly;

複数のCookieを除外するには、次のコマンドを実行します:

Header edit Set-Cookie ^(?!(IGNOREME=|IGNOREME1=)).*$ $0;HttpOnly;

HTTPストリクト・トランスポート・セキュリティ・ヘッダー

HTTPストリクト・トランスポート・セキュリティ(HSTS)とは、ブラウザがヘッダーに設定された特定の期間内に、常にSSL/TLSを介してHSTSヘッダーを返すサイトに接続する、セキュリティ強化機能です。ユーザーがURLでHTTPを使用している場合でも、HTTPを介したサーバーへの接続はすべて自動的にHTTPSに置き換えられます。HSTSヘッダーは、ブラウザ上のHTTPSクリックスルー・プロンプトも防止します。

HSTSポリシー・ヘッダーを有効にするには、SSL対応の仮想ホストに次を追加します:

<VirtualHost example.com:4443>
Header always set Strict-Transport-Security "max-age=63072000; preload; includeSubDomains"
</VirtualHost>

Referrer-Policy

Referrer-Policyヘッダーには、ユーザーが現在リクエストされているページにアクセスするためにたどる、前のWebページのアドレスが含まれています。

Referrer-Policyヘッダーには、アナリティクス、ロギング、キャッシュの最適化などの用途が数多くある一方で、トラッキングや情報窃取といった問題のある用途もあります。さらに、機密情報が誤って漏えいするなどの副作用もあります。

Referrer-Policyを有効にするには、Referrer-Policyヘッダーを次のように設定します:

Header always set Referrer-Policy "same-origin"

これにより、リファラが同一サイトのオリジンに送信され、クロスオリジン・リクエストにリファラ情報が含まれないことが保証されます。

クリックジャッキング攻撃を軽減するX-Frame-Optionsヘッダー

ノート:

CSPフレーム祖先によって、X-Frame-Optionsヘッダーは廃止されます。リソースに両方のポリシーがある場合、CSPフレーム祖先ポリシーが適用され、X-Frame-Optionsポリシーは無視されます。

X-Frame-Optionsは、サーバー側でクリックジャッキングを防止する方法です。

クリックジャッキング(UIリドレス攻撃とも呼ばれます)とは、攻撃者が透明または不透明な複数のレイヤーを使用してユーザーをだまし、ユーザーがクリックしていると思っているものとは違うボタンやリンクをページ上でクリックさせる方法です。

X-Frame-Optionsを有効にするには、X-Frame-Optionsヘッダーを次のように設定します:

Header setifempty X-Frame-Options SAMEORIGIN

X-Content-Type-Options

X-Content-Type-Optionsヘッダーは、MIMEスニッフィングの脆弱性から保護するためにサーバーで使用されるレスポンスHTTPヘッダーです。

MIMEスニッフィングは、特定のアセットに関する十分なメタデータ情報がない場合に、ブラウザがアセットのファイル形式を判断するために使用します。

レスポンスにX-Content-Type-Optionsヘッダーがないと、一部のブラウザは、レスポンスのコンテンツ・タイプやエンコーディングのプロパティが正しく定義されていない場合でも、これらを判断してしまいます。その結果、Webアプリケーションがクロスサイト・スクリプティング(XSS)攻撃を受けやすくなります。

たとえば、Internet ExplorerブラウザとSafariブラウザの一部のバージョンでは、content-typeがtext/plainのレスポンスにHTMLタグが含まれる場合、そのレスポンスはHTMLとして扱われます。

X-Content-Type-Optionsヘッダーを設定するには、ユーザー入力が含まれるすべてのレスポンスで次の変更を行います:

<IfModule mod_headers.c>
Header always set X-Content-Type-Options nosniff
</IfModule>

ServerSignature

ServerSignatureディレクティブを使用すると、Webサーバー生成ドキュメントにフッターを構成できます。

プロキシのチェーンでは、どのチェーン・サーバーが返されたエラー・メッセージを生成したかがフッターに示されます。構文は次のとおりです:

ServerSignature On | Off | EMail

デフォルト値はOffで、フッター行を抑制します。値Onは、サーバーのバージョン番号と、サービスを提供する仮想ホストのサーバー名を含むフッターを追加します。値EMailは、参照ドキュメントのServerAdminディレクティブで指定された値に対するmailto:参照を追加作成します。

ServerTokens

ServerTokensディレクティブを使用すると、サーバーのHTTPレスポンス・ヘッダーを構成できます。

このディレクティブは、クライアントに返送されるサーバー・レスポンス・ヘッダー・フィールドに、サーバーの汎用OSタイプの説明と、コンパイル済モジュールに関する情報を含めるかどうかを制御します。構文は次のとおりです:

ServerTokens Full | OS | Minor | Minimal | Major | Prod | None | Custom

デフォルト値はFullで、これにはサーバーのOSタイプおよびコンパイル済モジュールに関する情報が含まれます。値Prodは、最小限の情報を含めます。値 Noneは、サーバー・ヘッダーを削除します。値customは、2番目の引数として文字列を取り、それがサーバー・ヘッダーの値として使用されます。

ServerTokens Custom some-server-stringを使用して、Oracle HTTP Serverがレスポンス・ヘッダーを生成したときにWebサーバー・ソフトウェアを非表示にすることができます。バックエンド・サーバーがレスポンスを生成するときは、プロキシ・メカニズムに応じてバックエンド・サーバーからサーバー・レスポンス・ヘッダーが生成される場合があります。

ノート:

ServerTokens Custom some-server-stringは、Oracle HTTP Server 10gのServerHeader Off設定の置換文字列です。

CookieのSecureフラグ

セキュア・フラグは、HTTPレスポンス内でユーザーに新しいCookieを送信するときに設定できるオプションです。セキュア・フラグの目的は、Cookieがクリア・テキストで送信されないようにすることです。セキュアな属性がCookieに関連付けられている場合、ブラウザはこのようなCookieをクリア・テキストで送信しないため、認可されていないユーザーがCookieにアクセスすることを防ぎます。

サンプル構成:

<IfModule mod_headers.c>
Header edit Set-Cookie ^(.*)$ $1; Secure;
</IfModule>

CookieのSameSiteフラグ

Set-Cookie HTTPレスポンス・ヘッダーのSameSite属性を使用すると、Cookieをファーストパーティまたは同一サイトのコンテキストに制限する必要があるかどうかを宣言できます。

SameSite属性は3つの値を受け入れます。構文は次のとおりです:

SameSite=Lax | Strict | None

Lax: Cookieは、通常のクロスサイト・サブリクエスト(たとえば、イメージやフレームをサードパーティのサイトにロードするため)では送信されず、ユーザーがオリジン・サイトに移動するとき(つまり、リンクをたどるとき)に送信されます。
これは、SameSite属性が明示的に設定されていない場合のデフォルトのCookie値です。これにより、一部のクラスのクロスサイト・リクエスト・フォージェリ(CSRF)攻撃に対して、ユーザーが合理的に堅牢な防御を行うことができます。
Strict: Cookieは、ファーストパーティのコンテキストで送信されます。サードパーティのWebサイトによって開始されたリクエストとともに送信されるものではありません。
None: Cookieは、すべてのコンテキスト(つまり、ファーストパーティ・リクエストとクロスオリジン・リクエストの両方へのレスポンス)で送信されます。SameSite=Noneを設定する場合は、CookieのSecure属性も設定する必要があります。そうしないと、Cookieはブロックされます。