web-dev-qa-db-ja.com

NginxのHSTS：Strict-Transport-Securityヘッダーもサブドメインサーバーブロックに追加する必要がありますか？

nginx.confおよびexample.comのserverブロックを含む次のsubdomain.example.com構成ファイルを見てみましょう。

http {
    ...

    server {
        listen [::]:80 ipv6only=off default_server;
        server_name example.com;
        return 301 https://example.com$request_uri;
    }
    server {
        listen [::]:443 ipv6only=off ssl default_server;
        server_name example.com;
        add_header Strict-Transport-Security
            "max-age=63072000; includeSubDomains; preload" always;
        ...
    }

    server {
        listen [::]:80 ipv6only=off;
        server_name subdomain.example.com;
        return 301 https://subdomain.example.com$request_uri;
    }
    server {
        listen [::]:443 ipv6only=off ssl;
        server_name subdomain.example.com;
        add_header Strict-Transport-Security
            "max-age=63072000; includeSubDomains; preload" always; # <-- again ???
        ...
    }
}

ヘッダーのincludeSubDomains部分は、ヘッダーがすべてのサブドメインにも適用されることをブラウザーに明らかに示しています。

ただし、そのブラウザがsubdomain.example.comを表示する前にexample.comにアクセスする場合、それは何の助けにもなりませんか？このシナリオをカバーするには、すべてのサブドメインサーバーブロックにも同じadd_headerを追加する必要があります...

nginxsslhttpshttphttp-headers
4
Will

Strict-Transport-Securityの前にsub.example.comにアクセスした場合や、キャッシュされたHSTS情報の有効期限が切れている場合でも、クライアントが確実にヘッダーを取得できるように、HSTS example.comヘッダーをすべての場所に配置することをお勧めします。 。

includeSubDomainsフラグは、それが存在するすべてのサブドメインに影響します。これは、sub.example.comのincludeSubDomainsが*.sub.example.comではなく*.example.comで有効になることを意味します。 （これは、たとえばexample.co.ukが*.co.ukに影響を与える可能性がある場合は問題になるため、当然のことです。）

  • sub.sub.example.comを使用しない場合は、このフラグなしでサブドメインのStrict-Transport-Securityヘッダーを残すことができます。

  • subA.example.comはsubB.example.comを保護できません。

7
Esa Jokinen

正しい。 includeSubdomainsオプションは、現在のドメインが提供するHTMLページ内にリンクされているすべてのリソースにhttpsを適用するために使用されます。

引用 https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/ ：

たとえば、 https://www.example.com のHTML応答には、 https://example.com からのリソースへのリクエストを含めることができます。 HSTSは、example.comのすべてのサブドメインに設定されています。

また、場所{}ブロック内にadd_headerディレクティブを追加する場合、そのブロック内でadd_header Strict-Transport-Security ...を再定義する必要があることにも注意してください。もう一度引用：

NGINX構成ブロックは、囲んでいるブロックからadd_headerディレクティブを継承するため、最上位のサーバーブロックにadd_headerディレクティブを配置するだけで済みます。重要な例外が1つあります。ブロックにadd_headerディレクティブ自体が含まれている場合、それは囲んでいるブロックからヘッダーを継承せず、すべてのadd_headerディレクティブを再宣言する必要があります。

5
Luca Gibelli