目次
HTTP Strict Transport Security を使用するのはなぜですか?
nginx配置Strict Transport Security
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/HTTP_Strict_Transport_Security
次のコンテンツ ソース: https://www.freebuf.com/articles/web/66827.html
HTTP Strict Transport Security を使用するのはなぜですか?
HTTP Strict Transport Security (通常は HSTS と省略されます) は、HTTPS 経由でのみ現在のリソースにアクセスするようにブラウザーに指示し、HTTP メソッドを禁止するセキュリティ機能です。
0x01. Freebuf 百科事典: Strict-Transport-Security とは何ですか
owasp の定義から抜粋しています。
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)Web サイトは HTTP リクエストを受け入れて HTTPS にジャンプします。ユーザーは、ジャンプを開始する前に暗号化されていない方法でサーバーと通信できます。たとえば、ユーザーは http://foo.com または直接 foo.com と入力します。このように、中間者攻撃の潜在的な脅威があり、悪意のある Web サイトがリダイレクト プロセスを使用して、元の暗号化された情報ではなくユーザー情報に直接アクセスする可能性があります。Web サイトは、HTTP Strict Transport Security を通じて、この Web サイトが HTTP を使用して読み込まれることが禁止されていることをブラウザーに通知し、ブラウザーは HTTP を使用しようとするすべてのリクエストを HTTPS リクエストに自動的に置き換える必要があります。
0x02. なぜ Strict-Transport-Security を有効にする必要があるのですか
次のようなシナリオを考えてみましょう。
一部の Web サイトでは https が有効になっていますが、ユーザー エクスペリエンスを考慮するため (ユーザーは常に非常に怠け者であるため、一般に積極的に https を入力せず、ドメイン名を直接入力してアクセスします。デフォルトはhttp アクセス) をサポートしており、http アクセスにも対応しており、ユーザーが http にアクセスすると 302 リダイレクトがユーザーに返され、https のアドレスにリダイレクトされ、その後の訪問は https を使用して送信されます。この通信モードは問題ないようです。 , しかし、慎重に分析した結果、この通信モードにもリスクがあることがわかります。つまり、この 302 リダイレクトがハイジャックされ、改ざんされる可能性があります。悪意のある https サイトまたはフィッシング https サイトに変更された場合、フィッシング サイトに落ちても、データは安全であると言えるでしょうか?
改ざん 302 攻撃に対しては、サーバーで HTTP Strict Transport Security 機能を有効にすることが推奨されます。この機能の意味は次のとおりです。
ユーザーが htst 機能を有効にして Web サイトに安全にログインすると (hsts 機能をサポートするサイトでは、応答ヘッダーに Strict-Transport-Security が挿入されます)、htst をサポートするブラウザ (chrome.firefox など) は、このドメイン名を自動的に HSTS リストに追加します。ユーザーが次回 http を使用してこの Web サイトにアクセスした場合でも、htst 機能をサポートするブラウザーは自動的に https リクエストを送信します (ユーザーがキャッシュをクリアしていない場合、キャッシュが削除されている場合)。クリアされ、最初の訪問は依然としてプレーンテキストであり、その後のブラウザーは、http を送信する代わりに、サーバー応答ヘッダーの Strict-Transport-Security を受信して、ドメイン名を hsts キャッシュに追加し、リクエストを送信する前に http を https に変換します。最初に https にリダイレクトすることで、途中の 302 リダイレクト URL が改ざんされるのを防ぐことができます。通信のセキュリティをさらに向上させます。
上記は私自身の理解であり、以下は owasp 中国語サイトの hsts の説明です。
HSTS的作用是强制客户端（如浏览器）使用HTTPS与服务器创建连接。服务器开启HSTS的方法是，当客户端通过HTTPS发出请求时，在服务器返回的超文本传输协议响应头中包含Strict-Transport-Security字段。非加密传输时设置的HSTS字段无效。たとえば、https://example.com/ の応答ヘッダーには Strict-Transport-Security: max-age=31536000; includeSubDomains が含まれています。これは次の 2 つのことを意味します。
翌年 (つまり、31536000 秒) の間、ブラウザは HTTP リクエストを example.com またはそのサブドメインに送信するたびに、HTTPS を使用して接続を開始する必要があります。たとえば、ユーザーがハイパーリンクをクリックするか、アドレス バーに http://www.example.com/ を入力すると、ブラウザは自動的に http を https に変換し、リクエストを https://www.example に直接送信します。 com/.
今後 1 年間、example.com サーバーによって送信された TLS 証明書が無効な場合、ユーザーはブラウザーの警告を無視して Web サイトにアクセスし続けることはできません。
HSTS は、SSL ストリッピング攻撃を防御するために使用できます。SSL ストリッピング攻撃は、2009 年に Moxie Marlinspike によって発明された中間者攻撃の一種です。彼はその年の Black Hat Conference での「実際に SSL を破るための新しいトリック」と題した講演でこの攻撃を公にしました。SSL ストリッピングは、ブラウザがサーバーとの HTTPS 接続を作成できないようにすることで機能します。その前提は、ユーザーがアドレス バーに https:// を直接入力することはめったになく、ユーザーは常にリンクまたは 3xx リダイレクトをクリックして HTTP ページから HTTPS ページに入るということです。したがって、攻撃者は、ユーザーが HTTP ページにアクセスしたときに、https:// で始まるすべてのリンクを http:// に置き換えて HTTPS を阻止することができます。
HSTS は、SSL ストリッピング攻撃をほぼ解決できます。これは、ブラウザがサーバーとの安全な接続を確立している限り、リンクが HTTP に置き換えられた場合でも、ブラウザは HTTPS の使用を強制するためです。
また、中間者攻撃で独自の自己署名証明書が使用された場合、ブラウザーは警告を表示しますが、多くのユーザーは警告を無視します。HSTS ではこの問題が修正されており、サーバーが HSTS フィールドを送信した後は、ユーザーは警告を無視できなくなります。
0x03. Strict-Transport-Security のいくつかの欠点
ユーザーが初めて Web サイトにアクセスするときは、HSTS によって保護されません。これは、ブラウザーが初めてアクセスするときに HSTS を受信していないため、プレーンテキスト HTTP 経由でアクセスすることが可能です。現在、この問題を解決するには 2 つの解決策があり、1 つはブラウザに HSTS ドメイン名リストをプリセットすることであり、Google Chrome、Firefox、Internet Explorer、および Spartan はこの解決策を実装しています。2 つ目は、DNS レコードに HSTS 情報を追加することです。ただし、これには DNS のセキュリティを確保する必要があります。つまり、ドメイン ネーム システムのセキュリティ拡張機能を導入する必要があります。2014 年の時点では、このプログラムは大規模に展開されていません。
HSTS は一定期間が経過すると期限切れになるため (有効期間は max-age で指定されます)、ブラウザが HSTS ポリシーを適用するかどうかは現在のシステム時刻によって決まります。一部のオペレーティング システムでは、ネットワーク タイム プロトコルを通じてシステム時刻が更新されることがよくあります。たとえば、Ubuntu がネットワークに接続するたびに、OS X Lion は 9 分ごとに自動的にタイム サーバーに接続します。攻撃者は、NTP 情報を偽造し、間違った時刻を設定することで、HSTS をバイパスできます。解決策は、NTP 情報を認証するか、NTP による時間の大幅な増減を禁止することです。たとえば、Windows 8 では 7 日ごとに時刻が更新され、NTP によって設定された時刻と現在の時刻が毎回 15 時間を超えないようにする必要があります。
0x04. 私のテストの一部
1). テスト 1
対象ドメイン名: portal.fraudmetrix.cn (このサイトは hsts 機能をサポートしていません) Tongdun Technology のリスク管理管理システム (ソフトワイド、Tongdun Technology をベースに、ビッグデータに基づいて、不正防止に重点を置いています)。
最初の訪問: ブラウザのアドレス バーに「portal.fraudmetrix.cn」と入力します。
見られます：
このドメイン名は、Chrome ブラウザの hsts キャッシュにも、hsts のプリロード リストにもありません (Facebook、twitter などの Web サイトはプリロード リストに組み込まれているため、これらのサイトがリクエストされるたびに、ブラウザhttp を httpttps に自動的に変換します)。そのため、リクエストを送信する前に http を https リクエストに変換しません。
このサイトを Chrome ブラウザの hsts キャッシュに手動で追加してみましょう。
Chrome ブラウザの履歴が消去されていないことを前提として、再度このサイトにアクセスします。
ご覧のとおり、Chrome ブラウザの内部変換である 307 応答コードは、リクエストを送信する前に http を https に変換します。
注: Chrome ブラウザのキャッシュをクリアする前にアクセスが必要なのはなぜですか?
Chromeブラウザのキャッシュをクリアすると、hstsキャッシュに手動で追加したドメイン名もクリアされてしまい、期待した効果が得られなくなるためです。
2). テスト 2
まず Chrome ブラウザのキャッシュをクリアし、 ブラウザのアドレス バーにwww.alipay.comと入力します。
サイト www.alipay.com (Alipay) が Chrome ブラウザの組み込みプリロード リストに含まれていないことがわかります。そのため、Chrome ブラウザは、初めてアクセスしたときに http を https に変換しません。
代わりに、フロントエンド F5 ロード バランサー (BigIP) が http リクエストを https リクエストにリダイレクトします。
このリクエストに対する他の応答を続けて見てみましょう。
Alipay サイト サーバーが hsts 機能をサポートしており、応答ヘッダーに Strict-Transport-Security を挿入し、このヘッダーの有効期間を設定していることがわかります。キャッシュが手動でクリアされない限り、この有効期間内であれば、 , Chrome ブラウザは、このサイトに送信されるすべての http リクエストを送信する前に https に変換します。
ブラウザーが Strict-Transport-Security 応答ヘッダーを含むメッセージを受信すると、このサイトが hsts キャッシュに追加され、次回 http でアクセスされるときに自動的に https に変換されます。
このとき、 以下のhstsのキャッシュにwww.alipay.comがあるかどうかを確認します。
ご覧のとおり、www.alipay.com がChrome ブラウザのキャッシュに追加されました。
この時点で、ブラウザのキャッシュをクリアせずに、もう一度 www.alipay.comにアクセスしてください。
ご覧のとおり、おなじみの 307 応答コードです。ブラウザは内部変換を行って、http を https に変換しました。
3).その他
Facebook www.facebook.comが Chrome ブラウザの HSTS プリロード リストに追加されました。
非常に詳細な情報が記載されていることに気づきましたか?
私の大きな百度を見てみませんか？
Chrome ブラウザのキャッシュをクリアし、アドレス バーにwww.baidu.comと入力します。
残念ながら、私の Baidu は Chrome HSTS プリロード リストにも含まれていません。
このリクエスト内の他の応答メッセージを見てみましょう。
Strict-Transport-Security の影も見えませんでした。
nginx配置Strict Transport Security
たとえば、https://example.com/ の応答ヘッダーには Strict-Transport-Security: max-age=31536000; includeSubDomains が含まれています。これは次の 2 つのことを意味します。
翌年 (つまり、31536000 秒) の間、ブラウザは HTTP リクエストを example.com またはそのサブドメインに送信するたびに、HTTPS を使用して接続を開始する必要があります。たとえば、ユーザーがハイパーリンクをクリックするか、アドレス バーに http://www.example.com/ を入力すると、ブラウザは自動的に http を https に変換し、リクエストを https://www.example に直接送信します。 com/.
今後 1 年間、example.com サーバーによって送信された TLS 証明書が無効な場合、ユーザーはブラウザーの警告を無視して Web サイトにアクセスし続けることはできません。
nginx の設定ファイルは次のとおりです。
server {
listen 443 ssl http2;
server_name zt.test.com;
#配置ssl相关信息
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'AES128+EECDH:AES128+EDH:!aNULL';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/nginx/conf.d/ssl/dhparam.pem;
ssl_certificate /etc/nginx/conf.d/ssl/test.com.crt;
ssl_certificate_key /etc/nginx/conf.d/ssl/test.com.key;
#把下面的注释掉就可以了
#add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
access_log /var/log/nginx/zt.test.log main;
set $web_url $host;
location / {
proxy_pass http://ztweb.server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
set $domain default;
}
}