AD FS 2019 を使用した HTTP セキュリティ応答ヘッダーのカスタマイズ

  • [アーティクル]

Active Directory フェデレーション サービス (AD FS) 2019 では、AD FS によって送信される HTTP セキュリティ応答ヘッダーをカスタマイズする機能が追加されました。 これらのツールは、管理者が一般的なセキュリティの脆弱性から保護するのに役立ち、ブラウザーベースの保護メカニズムの最新の進歩を利用できるようにします。 この機能は、2 つの新しいコマンドレット (Get-AdfsResponseHeaders と Set-AdfsResponseHeaders) の導入によるものです。

注意

コマンドレット Get-AdfsResponseHeaders と Set-AdfsResponseHeaders を使用して HTTP セキュリティ応答ヘッダー (CORS ヘッダーを除く) をカスタマイズする機能は、AD FS 2016 にバックポートされました。 KB4493473 と KB4507459 をインストールすると AD FS 2016 に機能を追加できます。

この記事では、一般的に使用されるセキュリティ応答ヘッダーについて説明し、AD FS 2019 によって送信されるヘッダーをカスタマイズする方法について説明します。

注意

この記事では、AD FS 2019 がインストールされていることを前提としています。

シナリオ

次のシナリオでは、管理者がセキュリティ ヘッダーをカスタマイズする必要がある場合を示します。

  • 管理者は HTTP Strict-Transport-Security (HSTS) を有効にして、ハッキングされる可能性のあるパブリック Wi-Fi アクセスポイントから HTTP を使用して Web アプリにアクセスする可能性があるユーザーを保護できるようにしました。 HSTS は、すべての接続が HTTPS 暗号化を介するように強制します。 また、サブドメインの HSTS を有効にすることで、セキュリティをさらに強化したいと考えています。
  • 管理者は、Web ページがクリックジャックされるのを防ぐように X-Frame-Options 応答ヘッダーを構成しました。 X-Frame-Options では、iFrame 内の Web ページのレンダリングを防止します。 ただし、オリジン (ドメイン) が異なるアプリケーションからデータを (iFrame で) 表示するという新しいビジネス要件があるため、ヘッダー値をカスタマイズする必要があります。
  • 管理者は、ブラウザがクロス サイト スクリプティング攻撃を検出した場合に、ページをサニタイズしてブロックするために X-XSS-Protection を有効にしました。 X-XSS-Protection は、クロス サイト スクリプティング攻撃を防止します。 ただし、サニタイズした後にページを読み込むことができるように、ヘッダーをカスタマイズする必要があります。
  • 管理者は、シングル ページ アプリケーションが別のドメインで Web API にアクセスできるようにするために、クロス オリジン リソース共有 (CORS) を有効にし、AD FS でオリジン (ドメイン) を設定する必要があります。
  • 管理者は、コンテンツ セキュリティ ポリシー (CSP) ヘッダーを有効にすることで、クロスドメイン要求を禁止して、クロス サイト スクリプティング攻撃およびデータ インジェクション攻撃を防止しています。 ただし、新しいビジネス要件により、Web ページが任意のオリジンからイメージを読み込んで、メディアを信頼できるプロバイダーに制限できるように、ヘッダーをカスタマイズする必要があります。

HTTP セキュリティ応答ヘッダー

AD FS では、応答ヘッダーを Web ブラウザーに送信される発信 HTTP 応答に含めます。 次のスクリーンショットに示すように、Get-AdfsResponseHeaders コマンドレットを使用して、ヘッダーを一覧表示できます。

Screenshot that shows the PowerShell output from Get-AdfsResponseHeaders.

スクリーンショットの ResponseHeaders 属性は、すべての HTTP 応答で AD FS によって含まれるセキュリティ ヘッダーを識別します。 AD FS は、ResponseHeadersEnabled が True (既定値) に設定されている場合にのみ応答ヘッダーを送信します。 この値を False に設定すると、AD FS が HTTP 応答にセキュリティ ヘッダーを含めるのを防ぐことができます。 ただし、この設定は推奨されません。 次のコマンドを使用して、ResponseHeaders を False に設定できます。

Set-AdfsResponseHeaders -EnableResponseHeaders $false

HTTP Strict-Transport-Security (HSTS)

HTTP Strict-Transport-Security (HSTS) は Web セキュリティ ポリシー メカニズムであり、HTTP と HTTPS の両方のエンドポイントを持つサービスに対するプロトコル ダウングレード攻撃や Cookie ハイジャックを緩和するのに役立ちます。 それを使用すると、Web サーバーで、Web ブラウザーまたは他の準拠ユーザー エージェントは HTTPS のみを使用して対話し、HTTP プロトコルを使用してはならないことを宣言できます。

Web 認証トラフィック用のすべての AD FS エンドポイントは、HTTPS 経由専用に開かれます。 その結果、AD FS では HTTP Strict Transport Security ポリシー メカニズムによって提供される脅威が効果的に軽減されます。 既定では、HTTP にリスナーが存在しないため、HTTP にダウングレードできません。 ヘッダーをカスタマイズするには、次のパラメーターを設定します。

  • max-age=<expire-time>。 有効期限 (秒) は、HTTPS を使用してのみサイトにアクセスする必要がある時間を指定します。 既定値と推奨値は 31536000 秒 (1 年) です。
  • includeSubDomains。 このパラメーターは省略可能です。 指定した場合、HSTS ルールもすべてのサブドメインに適用されます。

HSTS のカスタマイズ

既定では、ヘッダーは有効で、max-age は 1 年に設定されています。ただし、管理者は、 max-age を変更するか (max-age の値を下げることはお勧めしません)、Set-AdfsResponseHeaders コマンドレットを使用してサブドメインの HSTS を有効にすることもできます。

Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=<seconds>; includeSubDomains"

例:

Set-AdfsResponseHeaders -SetHeaderName "Strict-Transport-Security" -SetHeaderValue "max-age=31536000; includeSubDomains"

既定では、ヘッダーは ResponseHeaders 属性に含まれていますが、管理者は Set-AdfsResponseHeaders コマンドレットを使用して ヘッダーを削除できます。

Set-AdfsResponseHeaders -RemoveHeaders "Strict-Transport-Security"

X-Frame-Options

既定では、AD FS は対話型サインインの実行時に外部アプリケーションが iframe を使用することを許可していません。 この構成により、特定のスタイルのフィッシング攻撃が防止されます。 セッション レベルのセキュリティが以前に確立されているため、iframe を使用して非対話型サインインを実行できます。

ただし、まれに、iframe 対応の対話型 AD FS サインイン ページを必要とする特定のアプリケーションを信頼する場合があります。 この目的には、X-Frame-Options ヘッダーが使用されます。

この HTTP セキュリティ応答ヘッダーは、ブラウザーが <frame>/<iframe> でページをレンダリングできるかどうかをブラウザーに通知するために使用されます。 ヘッダーは次の値のいずれかに設定できます。

  • deny。 フレーム内のページは表示されません。 この構成は既定値で、推奨される設定です。
  • sameorigin。 オリジンが Web ページのオリジンと同じ場合にのみ、ページはフレームに表示されます。 すべての先祖も同じオリジンになければ、このオプションは役に立ちません。
  • allow-from <specified origin>。 オリジン (https://www.".com など) がヘッダーの特定のオリジンと一致する場合にのみ、ページはフレームに表示されます。 一部のブラウザーでは、このオプションがサポートされていない場合があります。

X-Frame-Options のカスタマイズ

既定では、ヘッダーは [拒否] に設定されます。ただし、管理者は Set-AdfsResponseHeaders コマンドレットを使用して値を変更できます。

Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "<deny/sameorigin/allow-from<specified origin>>"

例:

Set-AdfsResponseHeaders -SetHeaderName "X-Frame-Options" -SetHeaderValue "allow-from https://www.example.com"

既定では、ヘッダーは ResponseHeaders 属性に含まれていますが、管理者は Set-AdfsResponseHeaders コマンドレットを使用して ヘッダーを削除できます。

Set-AdfsResponseHeaders -RemoveHeaders "X-Frame-Options"

X-XSS-Protection

この HTTP セキュリティ応答ヘッダーは、ブラウザーがクロス サイト スクリプティング (XSS) 攻撃を検出したときに、Web ページの読み込みを停止するために使用されます。 このアプローチは、XSS フィルター処理と呼ばれます。 ヘッダーは次の値のいずれかに設定できます。

  • 0 は、XSS フィルター処理を無効にします。 非推奨。
  • 1 は、XSS フィルター処理を有効にします。 XSS 攻撃が検出されると、ブラウザーはページをサニタイズします。
  • 1; mode=block は、XSS フィルター処理を有効にします。 XSS 攻撃が検出されると、ブラウザーはページのレンダリングを防止します。 この設定は既定値で、推奨される設定です。

X-XSS-Protection のカスタマイズ

既定では、ヘッダーは 1; mode=block; に設定されています。 ただし、管理者は Set-AdfsResponseHeaders コマンドレットを使用して値を変更できます。

Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "<0/1/1; mode=block/1; report=<reporting-uri>>"

例:

Set-AdfsResponseHeaders -SetHeaderName "X-XSS-Protection" -SetHeaderValue "1"

既定では、ヘッダーは ResponseHeaders 属性に含まれています。ただし、管理者はコマンドレット Set-AdfsResponseHeaders を使用して ヘッダーを削除できます。

Set-AdfsResponseHeaders -RemoveHeaders "X-XSS-Protection"

クロス オリジン リソース共有 (CORS) ヘッダー

Web ブラウザーのセキュリティにより、Web ページがスクリプト内から開始されたクロスオリジン要求を行えないようにします。 ただし、他のオリジン (ドメイン) 内のリソースへのアクセスが必要になる場合があります。 クロス オリジン リソース共有 (CORS) はW3C 標準で、サーバーによる同一オリジン ポリシーの緩和を許可します。 CORS を使用することで、サーバーが一部のクロス オリジン要求を明示的に許可しながら、、その他の要求を拒否することができます。

CORS 要求について理解を深めるために、次のシナリオでは、シングル ページ アプリケーション (SPA) が別のドメインで Web API を呼び出す必要があるインスタンスについて説明します。 さらに、SPA と API の両方が AD FS 2019 で構成され、AD FS で CORS が有効になっていることを考えます。 AD FS が HTTP 要求で CORS ヘッダーを識別し、ヘッダー値を検証し、応答に適切な CORS ヘッダーを含めることができます。 AD FS 2019 で CORS を有効にして構成する方法の詳細については、「CORS カスタマイズ」のセクションをご覧ください。 次のサンプル フローでは、シナリオについて説明します。

  1. ユーザーは、クライアント ブラウザーから SPA にアクセスし、認証のために AD FS 認証エンドポイントにリダイレクトされます。 SPA は暗黙的な許可フロー用に構成されているため、認証が成功すると、要求はブラウザーにアクセス + ID トークンを返します。

  2. ユーザー認証後、SPA に含まれるフロントエンド JavaScript は、Web API へのアクセスを要求します。 要求は、次のヘッダーを使用して AD FS にリダイレクトされます。

    • [Options] - ターゲット リソースの通信オプションについて説明します。
    • [Origin] - Web API のオリジンが含まれます。
    • [Access-Control-Request-Method] - 実際の要求が行われたときに使用される HTTP メソッド (DELETE など) を識別します。
    • [Access-Control-Request-Method] - 実際の要求が行われたときに使用される HTTP ヘッダーを識別します。

    注意

    CORS 要求は、標準の HTTP 要求に似ています。 ただし、オリジン ヘッダーが存在すると、受信要求が CORS 関連であることを示します。

  3. AD FS は、ヘッダーに含まれる Web API オリジンが AD FS で構成された信頼できるオリジンに一覧表示されていることを確認します。 信頼できるオリジンを変更する方法の詳細については、「CORS のカスタマイズ」をご覧ください。 次に、AD FS は次のヘッダーで応答します。

    • Access-Control-Allow-Origin - [Origin] ヘッダーと同じ値。
    • Access-Control-Allow-Method - [Access-Control-Request-Method] ヘッダーと同じ値。
    • Access-Control-Allow-Headers - [Access-Control-Request-Headers] ヘッダーと同じ値。

  4. ブラウザーは、次のヘッダーを含む実際の要求を送信します。

    • HTTP メソッド (DELETE など)。
    • [Origin] – Web API のオリジンが含まれます。
    • Access-Control-Allow-Headers 応答ヘッダーに含まれるすべてのヘッダー。

  5. 検証されると、AD FS は Access-Control-Allow-Origin 応答ヘッダーに Web API ドメイン (オリジン) を含めることで要求を承認します。

  6. Access-Control-Allow-Origin ヘッダーを含めることで、ブラウザーは要求された API を呼び出すことができます。

CORS のカスタマイズ

既定では、CORS 機能は有効になりません。ただし、管理者は Set-AdfsResponseHeaders コマンドレットを使用して機能を有効にできます。

Set-AdfsResponseHeaders -EnableCORS $true

有効にすると、管理者は同じコマンドレットを使用して信頼できるオリジンのリストを列挙できるようになります。 たとえば、次のコマンドはオリジン https&#58;//example1.com および https&#58;//example1.com からの CORS 要求を許可します。

Set-AdfsResponseHeaders -CORSTrustedOrigins https://example1.com,https://example2.com

注意

管理者は、信頼できるオリジンのリストに "*" を含めることで、任意のオリジンからの CORS 要求を許可できますが、セキュリティの脆弱性によりこの方法は推奨されておらず、選択した場合は警告メッセージが表示されます。

コンテンツ セキュリティ ポリシー (CSP)

この HTTP セキュリティ応答ヘッダーは、ブラウザーが悪意のあるコンテンツを誤って実行するのを防ぐことで、クロスサイト スクリプティング攻撃、クリックジャッキング攻撃、およびその他のデータ インジェクション攻撃を防ぐために使用されます。 コンテンツ セキュリティ ポリシー (CSP) をサポートしないブラウザーは、CSP 応答ヘッダーを無視します。

CSP のカスタマイズ

CSP ヘッダーのカスタマイズには、ブラウザーが Web ページに読み込みできるリソースを定義するセキュリティ ポリシーの変更が含まれます。 既定のセキュリティ ポリシーは次の値です。

Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval'; img-src 'self' data:;

default-src ディレクティブは、各ディレクティブを明示的にリストせずに -src ディレクティブを変更するために使用されます。 たとえば、次の例では、ポリシー 1 はポリシー 2 と同じです。

ポリシー 1

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'"

ポリシー 2

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "script-src 'self'; img-src 'self'; font-src 'self';
frame-src 'self'; manifest-src 'self'; media-src 'self';"

ディレクティブが明示的にリストされている場合、指定した値は default-src に指定された値をオーバーライドします。 次の例では、img-src は値を '*' (任意のオリジンからイメージを読むことができるようにする) とし、他の -src ディレクティブは値を 'self' (Web ページと同じオリジンに制限) として受け取ります。

Set-AdfsResponseHeaders -SetHeaderName "Content-Security-Policy" -SetHeaderValue "default-src 'self'; img-src *"

default-src ポリシーには、次のソースを定義できます。

  • 'self' - このソースを指定すると、読み込むコンテンツのオリジンが Web ページのオリジンに制限されます。
  • 'unsafe-inline' - ポリシーでこのソースを指定すると、インライン JavaScript と CSS を使用できるようになります。
  • 'unsafe-eval' - ポリシーでこのソースを指定すると、eval などの JavaScript メカニズムにテキストを使用できるようになります。
  • 'none' - このソースを指定すると、任意のオリジンから読み込まれるコンテンツが制限されます。
  • data: - データの指定: URI を使用すると、コンテンツ作成者は小さなファイルをドキュメントにインラインで埋め込むことができます。 使用は推奨されません。

注意

AD FS は認証プロセスで JavaScript を使用するため、既定のポリシーに "unsafe-inline" ソースと "unsafe-eval" ソースを含めることで JavaScript を有効にします。

カスタム ヘッダー

AD FS 2019 では、前述のセキュリティ応答ヘッダー (HSTS、CSP、X-Frame-Options、X-XSS-Protection、CORS) に加えて、新しいヘッダーを設定することができます。

たとえば、新しいヘッダー "TestHeader" と "TestHeaderValue" を値として設定できます。

Set-AdfsResponseHeaders -SetHeaderName "TestHeader" -SetHeaderValue "TestHeaderValue"

設定が完了すると、次の Fiddler スニペットに示すように、新しいヘッダーが AD FS 応答に送信されます。

Screenshot of Fiddler on the headers tab that highlights TestHeader: TestHeaderValue under Miscellaneous.

Web ブラウザーの互換性

次の表とリンクを使用して、各セキュリティ応答ヘッダーと互換性のある Web ブラウザーを特定します。

HTTP セキュリティ応答ヘッダー ブラウザーの互換性
HTTP Strict-Transport-Security (HSTS) HSTS ブラウザーの互換性
X-Frame-Options X-Frame-Options ブラウザーの互換性
X-XSS-Protection X-XSS-Protection ブラウザーの互換性
クロスオリジン リソース共有 (CORS) CORS ブラウザーの互換性
コンテンツ セキュリティ ポリシー (CSP) CSP ブラウザーの互換性

次へ