HTTP Strict Transport Security

HTTP
主要項目
リクエストメソッド
ヘッダーフィールド（英語版）
ステータスコード
認証方式
セキュリティホール

HTTP Strict Transport Security (略称 HSTS)とは、WebサーバーがWebブラウザに対して、現在接続しているドメイン（サブドメインを含む場合もある）に対するアクセスにおいて、次回以降HTTPの代わりにHTTPSを使うように伝達するセキュリティ機構である。HSTSはIETFの標準化過程にあるプロトコルであり、RFC 6797で規定されている。

概要

[編集]

WebサーバーがWebブラウザに対して、セキュアなHTTPSのみでサービスを提供したい場合、ユーザーの利便性といった観点から、HTTPで接続した際にHTTPSのURIにリダイレクトする場合がある。その際に、Webサーバーからのレスポンスにリダイレクトする指示を入れることになるが、HTTPは改竄検知機能を持たないため、攻撃者がこれを悪意のあるサイトにリダイレクトする指示に書き換えたり、HTTPSの内容をHTTPで中継(SSL Stripping)したとしても、Webブラウザはそれを知ることができず、クッキーハイジャックのような中間者攻撃を許してしまう。

HSTSではユーザーがWebブラウザにスキームがhttpであるURIを入力するなどしてHTTPで接続しようとした時に、予めWebサーバーがHSTSを有効にするよう指示してきたドメインの場合、Webブラウザが強制的にHTTPSでの接続に置き換えてアクセスすることで、この問題を解決する。

HSTSの仕組み

[編集]

HSTSポリシーは、サーバからユーザーエージェントへ、Strict-Transport-Securityという名前のHTTPレスポンスヘッダフィールドを介して伝達される。HSTSポリシーは、ユーザーエージェントがセキュアな方法でのみサーバにアクセスすべき期間を指定するRFC 6797。HSTSを使用するウェブサイトは、しばしば平文のHTTPを受け入れず、HTTP経由の接続を拒否するか、ユーザーを体系的にHTTPSへリダイレクトする（ただし、これは仕様で要求されているわけではない）。この結果、TLSを実行できないユーザーエージェントは、そのサイトに接続できなくなる。

この保護は、ユーザーが少なくとも一度そのサイトを訪れた後にのみ適用され、「Trust on first use」という原則に依存している。この保護の仕組みは、ユーザーがサイトへのHTTP（HTTPSではない）URLを入力または選択した際、ウェブブラウザなどのクライアントが、HTTPリクエストを行うことなく自動的にHTTPSにアップグレードすることで、HTTPによる中間者攻撃の発生を防ぐというものである。

HSTSプリロード

[編集]

HSTSは、サイトへの接続は常にTLS/SSLを使用すべきであることをブラウザに通知することで、この問題に対処するRFC 6797。ユーザーの初回訪問である場合、HSTSヘッダは攻撃者によって除去される可能性がある。Google Chrome、Firefox、およびInternet Explorer/Microsoft Edgeは、HSTSをサポートする既知のサイトを含むリストである「HSTSプリロードリスト」を実装することで、この制限に対処している[1][2][3][4]。このリストはブラウザと共に配布され、リストにあるサイトへの最初の要求からHTTPSを使用する。これにより、初回訪問時の攻撃を防ぐことができる。

HSTSの実装

[編集]

サーバは、HTTPS接続を介してヘッダを提供することでHSTSポリシーを実装する（HTTP経由のHSTSヘッダは無視される）[5]。例えば、サーバは、今後1年間（max-ageは秒単位で指定され、31,536,000は閏年でない1年に相当する）そのドメインへの将来のリクエストがHTTPSのみを使用するようにヘッダを送信することができる： Strict-Transport-Security: max-age=31536000。

ウェブアプリケーションがユーザーエージェントにHSTSポリシーを発行すると、準拠したユーザーエージェントは次のように動作するRFC 6797。

  1. ウェブアプリケーションを参照する安全でないリンクを、自動的に安全なリンクに変換する（例：http://example.com/some/page/は、サーバにアクセスする前にhttps://example.com/some/page/に変更される）。
  2. 接続のセキュリティが確保できない場合（例：サーバのTLS証明書が信頼できない場合）、ユーザーエージェントは接続を終了させなければならずRFC 6797、ユーザーがウェブアプリケーションにアクセスすることを許可すべきではないRFC 6797。

HSTSポリシーは、ウェブアプリケーションのユーザーを、いくつかの受動的（盗聴）および能動的なネットワーク攻撃から保護するのに役立つRFC 6797。中間者攻撃者がユーザーとウェブアプリケーションサーバ間のリクエストとレスポンスを傍受する能力は、ユーザーのブラウザがそのウェブアプリケーションに対してHSTSポリシーを有効にしている間は大幅に減少する。

セキュリティ上の考察

[編集]
  • HSTSはHTTPS接続が安全であることを前提としているため、TLSの安全性が脅かされる場合には意味を成さない場合がある。[6]
  • 最初の接続ではWebブラウザはHTTPS接続を強制するべきかどうかを知り得ないため、攻撃に対して脆弱である。[7]この問題に対する解決策として、上述のHSTSプリロードが存在する。
  • ジュネード・アリは、HSTSは偽ドメインの使用に対しては効果がないと指摘している。DNSベースの攻撃を使用することで、中間者攻撃者がHSTSプリロードリストにない人工的なドメインからトラフィックを提供することが可能になる[8]。これはDNSスプーフィング攻撃[9]や、単にwww.example.orgをwww.example.comと誤認させるようなドメイン名によって可能になる。
  • HSTSプリロードリストがあっても、HSTSは、BEASTやCRIME攻撃のような、TLS自体に対する高度な攻撃を防ぐことはできない。TLS自体への攻撃は、HSTSポリシーの範疇外である。また、サーバへの攻撃からも保護できない。
  • HSTSは期限付きであるため、偽のNTPパケットを使用するなどして、被害者のコンピュータの時刻をずらす攻撃に対して脆弱である[10]。

仕様の歴史

[編集]

HSTS仕様は、2012年10月2日にIESGによって標準化提案のRFCとして公開が承認された後、2012年11月19日にRFC 6797として公開された[11]。著者らは当初、2010年6月17日にインターネットドラフトとして提出した。インターネットドラフトへの転換に伴い、仕様名は「Strict Transport Security」（STS）から「HTTP Strict Transport Security」に変更された。これは、仕様がHTTPにのみ適用されるためである[12]。しかし、HSTS仕様で定義されているHTTPレスポンスヘッダフィールドは「Strict-Transport-Security」という名前のままである。

当時「STS」と呼ばれていた仕様の最後のいわゆる「コミュニティ版」は、コミュニティからのフィードバックに基づいた改訂を加え、2009年12月18日に公開された[13]。

PayPalのJeff Hodges、Collin Jackson、Adam Barthによる最初のドラフト仕様は、2009年9月18日に公開された[14]。

HSTS仕様は、JacksonとBarthが論文「ForceHTTPS: Protecting High-Security Web Sites from Network Attacks」で記述した独創的な研究に基づいている[15]。

さらに、HSTSは、Jeff HodgesとAndy Steingrueblが2010年の論文「The Need for Coherent Web Security Policy Framework(s)」で提唱した、ウェブセキュリティを改善するための全体的なビジョンの一側面を実現したものである[16]。

ブラウザの対応状況

[編集]
Chromium 45内のセキュリティ設定ページ。「en.wikipedia.org」ドメインのセキュリティポリシーの状態を示している。
Chromium 45内のHTTPS Strict Transport Securityの設定ページ。「en.wikipedia.org」ドメインのセキュリティポリシーの状態を示している。

脚注

[編集]
[脚注の使い方]
  1. ^ “Chromium HSTS Preloaded list”. cs.chromium.org. 2020年2月18日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  2. ^ Langley, Adam (2010年7月8日). “Strict Transport Security”. The Chromium Projects. 2019年9月1日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  3. ^ a b Keeler, David (2012年11月1日). “Preloading HSTS”. Mozilla Security Blog. 2020年2月24日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  4. ^ “HTTP Strict Transport Security comes to Internet Explorer” (2015年2月16日). 2015年11月15日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  5. ^ a b “Strict-Transport-Security” (英語). MDN Web Docs. Mozilla. 2020年3月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  6. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (2012年11月). “Section 14.3. Ramifications of HSTS Policy Establishment Only over Error-Free Secure Transport”. RFC 6797. IETF. 2013年6月29日閲覧。
  7. ^ Hodges, Jeff; Jackson, Collin; Barth, Adam (2012年11月). “Section 14.6. Bootstrap MITM Vulnerability”. RFC 6797. IETF. 2013年6月29日閲覧。
  8. ^ “Performing & Preventing SSL Stripping: A Plain-English Primer”. Cloudflare Blog (2017年10月20日). 2019年12月14日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  9. ^ Maksutov, A. A.; Cherepanov, I. A.; Alekseev, M. S. (2017). Detection and prevention of DNS spoofing attacks. 2017 Siberian Symposium on Data Science and Engineering (SSDSE). pp. 84–87. doi:10.1109/SSDSE.2017.8071970. ISBN 978-1-5386-1593-5. S2CID 44866769.
  10. ^ Selvi, Jose (17 October 2014). Bypassing HTTP Strict Transport Security (PDF). Black Hat Briefings. アムステルダム. 2014年10月22日時点のオリジナルよりアーカイブ (PDF). 2025年7月29日閲覧.
  11. ^ “[websec Protocol Action: 'HTTP Strict Transport Security (HSTS)' to Proposed Standard (draft-ietf-websec-strict-transport-sec-14.txt)]” (2012年10月2日). 2017年1月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  12. ^ Hodges, Jeff. “Re: [HASMAT "STS" moniker (was: IETF BoF @IETF-78 Maastricht: HASMAT...)]”. 2017年2月2日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  13. ^ “Strict Transport Security -06” (2009年12月18日). 2017年2月21日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  14. ^ “Strict Transport Security -05” (2009年9月18日). 2020年2月24日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  15. ^ “ForceHTTPS: Protecting High-Security Web Site from Network Attacks” (2008年4月). 2020年2月28日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  16. ^ Hodges, Jeff (2010年10月29日). “The Need for Coherent Web Security Policy Framework(s)”. 2017年8月14日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  17. ^ The Chromium Developers (2010年11月17日). “Strict Transport Security - The Chromium Projects”. 2020年3月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  18. ^ Hodges, Jeff (2009年9月18日). “fyi: Strict Transport Security specification”. 2020年2月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  19. ^ Opera Software ASA (2012年4月23日). “Web specifications support in Opera Presto 2.10”. 2018年6月20日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  20. ^ Langley, Adam [@agl__] (20 December 2013). “確認済み。~/Library/Cookies/HSTS.plist を参照。ある時点でのChromiumプリロードを含み、HSTSヘッダを処理する。”. 2019年5月9日時点のオリジナルよりアーカイブ. X（旧Twitter）より2025年7月29日閲覧.
  21. ^ “HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7”. windows.com. 2019年11月27日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  22. ^ “Internet Explorer Web Platform Status and Roadmap”. 2015年6月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。
  23. ^ “Project Spartan and the Windows 10 January Preview Build - IEBlog” (2015年1月22日). 2019年11月29日時点のオリジナルよりアーカイブ。2025年7月29日閲覧。

関連項目

[編集]

外部リンク

[編集]
プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装
クロスサイト攻撃
インジェクション (CWE-74)
スプーフィング攻撃
セッションハイジャック関連
DoS攻撃
サイドチャネル攻撃
不適切な入力確認 (CWE-20)
未分類
対策
関連項目
「https://ja.wikipedia.org/w/index.php?title=HTTP_Strict_Transport_Security&oldid=105792046」から取得