HTTP
静的リソース (英語) を含むすべての HTTP ベースの通信は、TLS を使用して [OWASP] (英語) 保護する必要があります。
フレームワークとして、Spring Security は HTTP 接続を処理しないため、HTTPS を直接サポートしません。ただし、HTTPS の使用に役立つ多くの機能を提供します。
Strict Transport Security
Spring Security は Strict Transport Security をサポートし、デフォルトで有効にします。
プロキシサーバー構成
プロキシサーバーを使用する場合は、アプリケーションが適切に構成されていることを確認することが重要です。例: 多くのアプリケーションには、https://192.168.0.107 のアプリケーションサーバーにリクエストを転送することで、https://example.com/ のリクエストに応答するロードバランサがあります。適切な設定がないと、アプリケーションサーバーはロードバランサの存在を認識できず、リクエストを https://192.168.0.107:8080 がリクエストされたかのように処理します。クライアント。
この問題を解決するには、プロキシが元のリクエストの詳細を渡す必要があり、アプリケーション側でその詳細を使用するように設定する必要があります。これには 2 種類のヘッダーが使用され、デプロイでどちらのヘッダーが適用されるかを把握することが重要です。
RFC 7239 [IETF] (英語) で定義されている標準の
Forwardedヘッダーは、元のホスト、プロトコル、クライアントを単一のヘッダーに保持します。RFC 7239 より前に存在した、
X-Forwarded-Host、X-Forwarded-Proto、X-Forwarded-Forなどの非標準のX-Forwarded-*ヘッダー。
ほとんどのプロキシは依然として標準の Forwarded ヘッダーではなく X-Forwarded-* ヘッダーを送信しますが、Spring Framework や Reactor Netty、Jetty などのサーバーは両方を理解します。どちらか一方だけが使用されていると決めつけないでください。
どちらの種類のヘッダーも、プロキシが上書きしない限りクライアントによって提供されるため、信頼できるプロキシを介さずにこれらのヘッダーを信頼するアプリケーションは、実際とは異なるホスト、プロトコル、クライアントアドレス経由でリクエストが到着したと誤認する可能性があります。 |
このため、ネットワークのエッジにあるプロキシは、外部から到着する転送ヘッダーを、どちらの種類のヘッダーについても削除または上書きするように設定する必要があります。Forwarded ヘッダーのみを削除して X-Forwarded-* ヘッダーを通過させる（またはその逆）と、アプリケーションはもう一方のヘッダーセットによる同様のなりすまし攻撃に対して脆弱なままになります。アプリケーションには、制御するプロキシによって追加されたヘッダーのみが届くようにしてください。
エッジで信頼できない値が処理されると、アプリケーションサーバーでヘッダーを適用するように構成できます。例: Tomcat は RemoteIpValve [Apache] (英語) を使用し、Jetty は ForwardedRequestCustomizer (英語) を使用します。あるいは、Spring ユーザーは、サーブレットスタックで ForwardedHeaderFilter を、リアクティブスタックで ForwardedHeaderTransformer を使用することもできます。どちらも Forwarded ヘッダーと X-Forwarded-* ヘッダーを処理し、どちらもヘッダーを適用する代わりに削除するように構成できます。これは、アプリケーションがプロキシの背後にない場合に便利です。
Spring Boot ユーザーは、server.forward-headers-strategy プロパティを使用してアプリケーションを構成できます。詳細については、Spring Boot ドキュメントを参照してください。
