すべての応答にHSTSヘッダーを設定しないことの危険性は何ですか？
Webアプリケーションは、/assets/*へのリクエストへの応答でHSTSヘッダーのみを設定します。その他の応答には、HSTSヘッダーは含まれません。
最初は安全ではないように見えますが、インデックスページを開いているブラウザはすべてのアセットの読み込みをすぐにフォローアップします。その結果、HSTSヘッダーが表示され、今後のすべてのリクエストで尊重されます。
何か足りないものはありますか？この奇妙な設定は問題ありませんか？
すべてのHTTPS応答にHSTSヘッダーを設定することをお勧めしますが、HSTSポリシーは max-age 秒間キャッシュされるため、これにより実質的に同じレベルのセキュリティが提供されます。 Strict-Transport-Securityヘッダーがなくてもポリシーが削除されないことが定義されていますが、max-ageにゼロ値を設定するだけです（RFC 6796 6.1.1 、- 5. ＆ 12.5 ）。また、設定値が低すぎると、期限切れが早すぎます。
これらの設定により、max-age秒以内に信頼済みネットワークのページにアクセスしたユーザー（または、ブラウザーのHSTSヘッダーをより正確に見たユーザー）を保護できます。 HSTSヘッダーを提供するURLがすべての訪問で読み込まれる場合、これは本当にこれを危険にさらすことはありません。それにもかかわらず、ホスト名レベルでこの構成を移動する理由notは何もわかりません。これも間違いである可能性があります。
ただし、これはユーザーを保護することを妨げますbeforeこれまでにサイトにアクセスしたことがある（次のステップとレベルになります） Strict-Transport-SecurityとincludeSubDomainsとpreloadの両方が/への要求に応じて存在するため、ドメインを HSTSプリロードされたリスト 。これは、example.com、*.example.com、*.*.example.comなど全体を事前に保護する唯一の方法です。また、 hstspreload.org では、max-ageが少なくとも31536000秒（1年）である必要があります。
奇妙に思えます。説明する2つのシナリオを次に示します。
シナリオ1
たぶんブラウザの設定では、アセットが読み込まれないようになっている可能性があります。たとえば、モバイルデータ上のモバイルデバイスでは、帯域幅を節約するためにアセットが読み込まれない場合があります。
次に、HSTSが保護するすべての脆弱性を利用できるようになります。
シナリオ2（このシナリオは、以下のコメントでの議論の後に編集されました）
さらに、アセットの読み込みにこのような制限がなくても、インデックスページのHSTSヘッダーがなければ、Webアプリを攻撃にさらしたままにします。その結果、攻撃者はすでに初期応答を任意のページに置き換えることに成功している可能性があります。 httpを介して、彼らの選択の。これがインデックスページのロードで発生した場合、次に発生するはずのアセットのロードは無関係になり、ブラウザはそれらのアセットを要求することも、応答にHSTSヘッダーを表示することもありません。
具体的な例として、SSLを取り除いた中間者（MiTM）攻撃を考えてみましょう。 SSLストリッピングMiTM攻撃では、https接続はMiTMによってhttpに変換されます。さて、攻撃者がWebアプリからのHSTSヘッダーの応答を単に無視し、任意の応答をHSTSヘッダーなしでhttp経由でクライアントに返すのを防ぐにはどうすればよいでしょうか。ここで、プリロードリストが重要になります。
主要なブラウザはすべて、HSTSをサポートする既知のサイトを含むHSTSプリロードリストを実装しています。したがって、ブラウザはHSTSを実装していることを知るために、サイトからの実際の応答の受信に依存する必要がないため、ブラウザはhttpsの使用を強制します。では、これらのHSTSプリロードリストは、ブラウザで使用するためにどのように生成されるのでしょうか。
たとえば、Firefoxの場合（ blog.mozilla.org/security を参照）、
プリロードリストを作成するには、Chromeのリストで「mode：“ force-https”」を使用してリクエストをすべてのホストに送信します。ホストが有効なHSTSヘッダーで応答する場合のみ。
そのため、WebアプリのインデックスページにHSTSヘッダーを含めないと、プリロードリストから除外され、HSTS（プリロードリストで実装）が通常は防御する攻撃に対してWebアプリが開かれたままになる可能性があります。