web-dev-qa-db-ja.com

セキュアHTTPヘッダー-WAFまたはコードレベルのどこに実装する必要がありますか？

REST APIがインターネットに公開されており、フォームベース認証を備えた別のアプリケーションがあります。これらのアプリケーションはWebアプリケーションファイアウォールの背後にあります。

質問は、WAFまたはコードレベルで、以下のセキュリティHTTPヘッダーをどこに実装する必要があるかです。

  • X-XSS保護
  • X-Frame-Options
  • X-Content-Type-Options
  • X-Permitted-Cross-Domain-Policies
  • HTTP Strict Transport Security
  • HTTP公開鍵のピン留め
  • コンテンツセキュリティポリシー
  • リファラーポリシー
  • 機能ポリシー

2番目の質問：ヘッダーがコードレベルとWAFレベルで構成されている場合はどうなりますか？ヘッダーを2回取得しますが、間違っていますか？

web-applicationxsshttpwafheader
12
Mathev

クライアントの観点からは、これらのヘッダーがどこに実装されているかは重要ではありません。のみかどうか実装されています。

ただし、展開の観点からは、WAFは追加の防御線としてのみ扱われ、単一の防御線として扱われるべきではありません。これは、少なくともほとんどのヘッダーについて、Webアプリケーション自体とセキュリティヘッダーの適切な設定で適切な入力チェックを行う必要があることを意味します。もちろん、HPKPは、WAFである可能性のある証明書を所有するTLSエンドポイントでのみ設定できます（ 非推奨 ）以降に設定する必要がある場合。

Webアプリケーション自体にセキュリティヘッダーを設定することも、開発の観点からは優れています。開発者は、特定の入力の予想されるタイプとそのチェック方法を知っている必要があるだけでなく、アプリケーションがどのように機能するか、たとえば最も厳しいContent-Security-Policyが何であるかについても知っています。代わりに、WAFは、アプリケーションの深い知識がない別のチームによって配備されることが多いため、セキュリティヘッダーをアプリケーションが許容できる最も厳しい値に簡単に設定できません。

したがって、サードパーティのアプリケーションの場合のように、アプリケーション自体で設定できない場合にのみWAFで設定する必要があります。ただし、追加の防御線として、WAFを使用してヘッダーが存在し、ヘッダーが十分に厳格であることを確認できます。これは、開発者がヘッダーを設定するのを忘れた可能性があるためです。

19
Steffen Ullrich

いくつかの考えのためだけに、これは言うまでもなく適切な推奨事項です。

  • 必要な柔軟性のレベルを確認します。これらのヘッダーの一部を特別な状況（たとえば、アプリケーションの状態に応じて）で設定する必要がある場合は、アプリケーションに保持するしかありません。
  • WAFの背後に複数のアプリがある場合、それらのallが同じルールセットを必要とすることを確認できますか？条件付きルールは、一般的なルールよりも実装が難しい場合があります
  • ルールをソース管理下に保持しますか（ログwho実装whichルールwhen）をログに記録できます）？次に、追加のレイヤーではなく、アプリケーションの一部にする必要があります

構成を混在させたくない場合（例：ここにいくつかのヘッダーを設定し、そこにいくつかヘッダーを設定します）、アプリケーションでそれらを保持します

5
Nico Haase