トップQs
タイムライン
チャット
視点
HTTP Strict Transport Security
ウィキペディアから
Remove ads
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を使用する。これにより、初回訪問時の攻撃を防ぐことができる。
Remove ads
HSTSの実装
サーバは、HTTPS接続を介してヘッダを提供することでHSTSポリシーを実装する（HTTP経由のHSTSヘッダは無視される）[5]。例えば、サーバは、今後1年間（max-ageは秒単位で指定され、31,536,000は閏年でない1年に相当する）そのドメインへの将来のリクエストがHTTPSのみを使用するようにヘッダを送信することができる： Strict-Transport-Security: max-age=31536000。
ウェブアプリケーションがユーザーエージェントにHSTSポリシーを発行すると、準拠したユーザーエージェントは次のように動作するRFC 6797。
- ウェブアプリケーションを参照する安全でないリンクを、自動的に安全なリンクに変換する（例：
http://example.com/some/page/は、サーバにアクセスする前にhttps://example.com/some/page/に変更される）。 - 接続のセキュリティが確保できない場合（例：サーバのTLS証明書が信頼できない場合）、ユーザーエージェントは接続を終了させなければならずRFC 6797、ユーザーがウェブアプリケーションにアクセスすることを許可すべきではないRFC 6797。
HSTSポリシーは、ウェブアプリケーションのユーザーを、いくつかの受動的（盗聴）および能動的なネットワーク攻撃から保護するのに役立つRFC 6797。中間者攻撃者がユーザーとウェブアプリケーションサーバ間のリクエストとレスポンスを傍受する能力は、ユーザーのブラウザがそのウェブアプリケーションに対してHSTSポリシーを有効にしている間は大幅に減少する。
Remove ads
セキュリティ上の考察
- 最初の接続ではWebブラウザはHTTPS接続を強制するべきかどうかを知り得ないため、攻撃に対して脆弱である。[7]この問題に対する解決策として、上述のHSTSプリロードが存在する。
- ジュネード・アリは、HSTSは偽ドメインの使用に対しては効果がないと指摘している。DNSベースの攻撃を使用することで、中間者攻撃者がHSTSプリロードリストにない人工的なドメインからトラフィックを提供することが可能になる[8]。これはDNSスプーフィング攻撃[9]や、単にwww.example.orgをwww.example.comと誤認させるようなドメイン名によって可能になる。
仕様の歴史
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]。
Remove ads
ブラウザの対応状況
- ChromiumおよびGoogle Chrome バージョン4.0.211.0以降[17][18]
- Firefox バージョン4以降[5]。Firefox 17で、MozillaはHSTSをサポートするウェブサイトのリストを統合した[3]。
- Opera バージョン12以降[19]
- Safari OS X Mavericks（バージョン10.9、2013年後半）以降[20]
- Internet Explorer 11（Windows 8.1およびWindows 7、KB3058515インストール済み）（2015年6月にWindows Updateとしてリリース）[21]
- Microsoft EdgeおよびInternet Explorer 11（Windows 10）[22][23]
- BlackBerry 10 BrowserおよびWebView（BlackBerry OS 10.3.3以降）
Remove ads
脚注
関連項目
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads