web-dev-qa-db-ja.com

404エラーページのHSTSヘッダーを返す必要がありますか？

[〜＃〜] hsts [〜＃〜] が有効になるように.NET Webアプリケーションをセットアップしました。 https://gf.dev/hsts-test にアクセスしてこれを確認し、URLに入力すると、HSTS保護が存在することが示されます。

結果は次のとおりです。

Strict-Transport-Security max-age = 31536000; includeSubDomains

しかし、クライアントはまだそうではないと言って戻ってきました。メインURLがHSTSに対応している間、テストベクターURLは対応していません。

例えば：

  1. https://gf.dev/hsts-test に移動します
  2. https://nvisium.com を入力し、[テストヘッダー]をクリックします
  3. 結果は、HSTSが有効になっていることを示しています。
  4. テストを再度実行しますが、 https://nvisium.com/test.xml （test.xmlは存在しません）
  5. 結果は、HSTSが有効になっていないことを示しています。

HSTSテストに合格した既存のリソースにURLを配置すると、.

私の質問は、彼らはポイントを持っていますか？または、これは彼らが使用する侵入テストソフトウェアの1つで偽陽性テストですか？

悪魔の擁護者を演じていますが、存在しないリソースを要求した場合でも、Webサイトは応答を返送し、クライアントがhstsを使用することを強制しないと主張することができます。

tlsweb-applicationhsts
4
Fylix

最初に/test.xmlのような存在しない任意のリソースを取得することは、サイトの通常の操作の範囲内ではないため、ブラウザがHSTSヘッダーをどこかで見た後（またはプリロードした後）、問題は発生しなくなります。ホスト名レベル（およびincludeSubDomainsを使用したドメインレベル）でHTTPSにアップグレードします。

また、攻撃者が404ではなく200応答につながるURLを使用するかどうかに大きな違いはありません。キャッシュされたHSTSがない場合、攻撃は両方で同様に機能します。このテストの失敗について不平を言うことは、HSTSがどのように機能し、何のためにあるのかを理解していないことを示しています。

そうは言っても、アプリケーションの代わりにWebサーバーにHSTSヘッダーを追加すると、このようなまれなボーダーケースでヘッダーが表示される可能性が少し高くなりますが、HSTSプリロードはこれを処理しますが、以前のサイト。

HSTSプリロード

すでにincludeSubDomainsがあるので、プリロードの準備ができているはずです。

  1. ヘッダーにpreloadを追加します。

    Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

  2. https://hstspreload.org/ でプリロードするサイトを送信します

Microsoft IISでHSTSヘッダーを追加する

IIS 10.0 1709以降、HSTSがネイティブでサポートされているため、 <hsts> を使用できます。

<site name="Contoso" id="1">
    . . .
    <hsts enabled="true" max-age="31536000" 
          includeSubDomains="true" preload="true" 
          redirectHttpToHttps="true" />
</site>

その前に、あなたはしなければなりませんでした

  • hTTPからHTTPSへのリダイレクトを個別に行う

    <?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpRedirect enabled="true" 
                      destination="https://contoso.com" 
                      httpResponseStatus="Permanent" />
    </system.webServer>
</configuration>

  • <customHeaders> を使用してヘッダーを追加します：

    <?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Strict-Transport-Security" 
                     value="max-age=31536000; includeSubDomains; preload" />
            </customHeaders>
        </httpProtocol>
    </system.webServer>
</configuration>

これはMicrosoft Windowsであるため、同じ画像に両方のGUIに相当するものがあります。

HSTS on IIS GUI

3
Esa Jokinen

攻撃者がサイトへのリンクをクリックするように被害者をだまし、ブラウザがhttpを使用し、強力なネットワーク位置にいる攻撃者が悪意のあるコンテンツを傍受して送信し、コンテンツがサイトからのコンテンツであると被害者に信じ込ませたとします。

HSTSはどのように役立ちますか？被害者が以前にあなたのサイトを訪問した場合、彼らのブラウザにはドメインのHSTS "フラグ"があり、リンクをクリックするとブラウザは代わりにhttpsを使用して攻撃を阻止します。しかし、被害者が以前にサイトを訪れたことがある場合に限ります。

以前にサイトにアクセスしたことがない、またはあまりにも前にサイトにアクセスした被害者はどうですか？これがHSTSプリロードの目的です。 HSTSプリロードリストにサイトを追加することをお勧めします。これにより、404エラーページにHSTSヘッダーが存在するかどうかに関係なく、攻撃が阻止されます。

記述されているように、404エラーページのHSTSは攻撃に影響しません。攻撃者から提供されたリンクが404につながるかどうかは問題ではありません。攻撃者はどちらの方法でも応答を傍受して置き換えることができます。重要なのは、このブラウザーが以前に（制限時間内に）サイトにアクセスしたかどうか、およびHSTSプリロード（および更新されたブラウザー）を使用したかどうかです。

Nginxウェブサーバーでは、エラーページにHSTS応答ヘッダーを追加する方法もあります。オプションの「常に」引数を " add_header "に追加します。 IISでそれを行う方法や、IISでも可能かどうかはわかりませんが、多分それは可能です。あなたの代わりに、私はこれを修正しますが、それがどのように行われるかわかりませんセキュリティ上の問題。

4
Z.T.