メインコンテンツまでスキップ

2. Overview (概要)

このセクションでは、使用事例について説明し、HSTSポリシーを要約し、脅威モデル、対処されていない脅威、および派生した要件について議論します。

2.1 Use Cases (使用事例)​

高レベルの使用事例は、以下の組み合わせです:

  • さまざまなウェブサイト（任意のサイトや既知のサイト）と安全な方法で対話したいウェブブラウザユーザー。

  • 自分自身とユーザーの両方のために、サイトを可能な限り安全な方法で提供したいウェブサイト展開者。

2.2 HTTP Strict Transport Security Policy Effects (HTTP厳格トランスポートセキュリティポリシーの効果)​

適合するUA (User Agent) とこのようなポリシーを実装するウェブリソースのホスト（HSTSホスト (HSTS Host)）との対話に適用された場合のHSTSポリシーの効果は、以下のように要約されます:

  1. UAは、HSTSホストへの非セキュアなURI参照を、それらを参照解決する前にセキュアなURI参照に変換します。

  2. UAは、すべてのセキュアトランスポートエラーまたは警告に遭遇した際に、セキュアトランスポート接続の試みを終了します。

2.3 Threat Model (脅威モデル)​

HSTSは、3つのクラスの脅威に関係します: 受動的ネットワーク攻撃者 (Passive Network Attackers)、能動的ネットワーク攻撃者 (Active Network Attackers)、および不完全なウェブ開発者 (Imperfect Web Developers)。ただし、他の2つのクラスの脅威に対する明示的な対策ではありません: フィッシング (Phishing) とマルウェア (Malware)。対処された脅威と対処されていない脅威について、以下で簡単に説明します。

詳細および参考文献については、[ForceHTTPS]のセクション2を参照してください。

2.3.1 Threats Addressed (対処された脅威)​

2.3.1.1 Passive Network Attackers (受動的ネットワーク攻撃者)​

ユーザーがローカル無線ネットワーク（例えば、802.11ベースの無線LAN）上でウェブを閲覧している場合、近くの攻撃者は、ローカル無線ネットワーク自体が保護されているかどうかに関係なく、HTTPなどのユーザーの暗号化されていないインターネットプロトコルベースの接続を盗聴できる可能性があります [BeckTews09]。自由に利用可能な無線スニッフィングツールキット（例えば、[Aircrack-ng]）により、ローカル無線ネットワークが安全な方法で動作している場合でも、このような受動的盗聴攻撃が可能になります。このようなツールを使用する受動的ネットワーク攻撃者は、セッション識別子/Cookieを盗み、認証資格情報を含むCookieを取得することでユーザーのウェブセッションをハイジャックできます [ForceHTTPS]。例えば、Firesheep（ウェブブラウザ拡張機能）[Firesheep]などの広く利用可能なツールが存在し、これらのツールを使用して、さまざまなウェブアプリケーションに対する他のローカルユーザーのセッションCookieを取得できます。

このような脅威を軽減するために、一部のウェブサイトは、エンドツーエンドのセキュアトランスポートを使用したアクセスをサポート（ただし通常は強制しない）しています - 例えば、"https"スキーム [RFC2818]で構築されたURIを通じてシグナルされます。これにより、ユーザーは、セキュアトランスポートを使用してこのようなサービスにアクセスすることで、受動的ネットワーク攻撃者から保護されると想定する可能性があります。残念ながら、実際の展開では、これは多くの場合そうではありません。なぜなら、セッション識別子は、非セキュアトランスポート経由で提供されるサービスのバージョンとの相互運用を可能にするために、通常、非SecureなCookieに格納されているためです（"Secure Cookie"とは、"Secure"属性 [RFC6265]を含むCookieを指します）。例えば、ウェブサイト（電子メールサービスなど）がセッション識別子を非SecureなCookieに格納している場合、ユーザーのUAがそのサイトに対して1回でも非セキュアなHTTPリクエストを行うと、攻撃者がユーザーのセッションをハイジャックできるようになります。

2.3.1.2 Active Network Attackers (能動的ネットワーク攻撃者)​

決意の固い攻撃者は、ユーザーのDNSサーバーになりすますか、無線ネットワーク上でネットワークフレームをスプーフィングするか、または類似の名前の悪意のある双子アクセスポイント (Evil Twin Access Point)を提供することで、能動的攻撃を仕掛けることができます。ユーザーが無線ホームルーターの背後にいる場合、攻撃者は、デフォルトのパスワードやその他の脆弱性を使用してルーターを再構成しようとする可能性があります。銀行などの一部のウェブサイトは、このような能動的攻撃者から自分自身とユーザーを保護するために、エンドツーエンドのセキュアトランスポートに依存しています。残念ながら、ブラウザは、セキュアトランスポートを誤った方法で展開しているサイト（例えば、自分自身で証明書を生成して自己署名する場合（ユーザーのブラウザに証明機関 (Certification Authority, CA)証明書も配布するのではなく））に対して使用可能にするために、ユーザーがこれらの保護を簡単にオプトアウトできるようにしています。

2.3.1.3 Web Site Development and Deployment Bugs (ウェブサイト開発および展開のバグ)​

本来統一的にセキュアなサイト（つまり、そのすべてのコンテンツが"https" URIを介して具体化されているサイト）のセキュリティは、カスケーディングスタイルシート (Cascading Style Sheet) やSWF（Shockwave Flash）ムービーを非セキュア接続経由で読み込むなどの単純なミスを能動的攻撃者が悪用することで、完全に侵害される可能性があります（カスケーディングスタイルシートとSWFムービーはどちらも埋め込みページをスクリプト化できるという事実は、多くのウェブ開発者を驚かせます。さらに、SWFファイルが非セキュア接続を介して埋め込まれた場合、一部のブラウザはいわゆる"混合コンテンツ警告"を発行しません）。サイトの開発者がログインページの"混合コンテンツ"を注意深く精査したとしても、ウェブサイト全体のどこか1箇所での非セキュアな埋め込みは、ログインページのセキュリティを侵害します。なぜなら、攻撃者は、別の非セキュアに読み込まれたサイトページにコード（例えば、スクリプト）を注入することで、ログインページをスクリプト化（つまり、制御）できるためです。

注意 (NOTE): 上記で使用されている"混合コンテンツ (Mixed content)"という用語（[W3C.REC-wsc-ui-20100812]のセクション5.3も参照）は、本仕様で"混合セキュリティコンテキスト (Mixed Security Context)"としてラベル付けされている概念を指しており、XMLやHTMLなどのマークアップ言語のコンテキストで使用される同じ"混合コンテンツ"という用語と混同しないでください。

2.3.2 Threats Not Addressed (対処されていない脅威)​

2.3.2.1 Phishing (フィッシング)​

フィッシング攻撃は、攻撃者が実際のウェブサイトとは異なるドメイン上に偽のウェブサイトをホストしてユーザーから認証資格情報を要求する場合に発生します。おそらく、電子メールでリンクを送信して偽サイトにトラフィックを誘導します。ユーザーは実際のウェブサイトと偽のウェブサイトを区別することが困難であるため、フィッシング攻撃は非常に効果的である可能性があります。HSTS自体はフィッシングに対する防御ではありません。むしろ、ブラウザにセッションの整合性と長期認証トークンを保護するよう指示することで、多くの既存のフィッシング防御を補完します [ForceHTTPS]。

2.3.2.2 Malware and Browser Vulnerabilities (マルウェアとブラウザの脆弱性)​

HSTSはブラウザのセキュリティメカニズムとして実装されているため、セッションを保護するためにユーザーのシステムの信頼性に依存しています。ユーザーのシステム上で実行される悪意のあるコードは、HSTSの有無にかかわらず、ブラウジングセッションを侵害できます。

2.4 Requirements (要件)​

このセクションでは、上記の使用事例と脅威から派生したさまざまな要件を特定して列挙し、HTTP Strict Transport Securityが対処する詳細なコア要件と、直接対処されていない付随的要件の両方をリストします。

2.4.1 Overall Requirement (全体的な要件)​

  • 受動的および能動的ネットワーク攻撃者、ウェブサイトの開発および展開のバグ、および不安全なユーザーアクションから生じる、ウェブブラウザユーザーとウェブサイト展開者へのリスクを最小化する。

2.4.1.1 Detailed Core Requirements (詳細なコア要件)​

これらのコア要件は、全体的な要件から派生し、本仕様で対処されています。

  1. ウェブサイトは、厳格なセキュリティポリシーを使用してアクセスすべきであることをUAに宣言できる必要があります (しなければならない)。

  2. ウェブサイトは、非セキュアに接触するUAに対して、セキュアに接触するよう指示できる必要があります (しなければならない)。

  3. UAは、厳格なセキュリティポリシーの有効化を通知するウェブサイトに関する永続的なデータを、ウェブサイトが宣言した期間保持する必要があります (しなければならない)。さらに、UAは、ウェブサイトが情報を更新できるように、"最新の"厳格なセキュリティポリシー情報をキャッシュする必要があります (しなければならない)。

  4. UAは、厳格なセキュリティポリシーが有効になっているウェブサイトに対して、すべての非セキュアなUA "http" URI読み込みを"https"セキュアスキームを使用するように書き換える必要があります (しなければならない)。

  5. ウェブサイト管理者は、厳格なセキュリティポリシーが有効になっている上位レベルドメインのサブドメインに対して厳格なセキュリティポリシーの適用を通知できる必要があり (しなければならず)、UAはそのようなポリシーを実施する必要があります (しなければならない)。

    例えば、example.comとfoo.example.comの両方が、bar.foo.example.comに対してポリシーを設定できます。

  6. UAは、厳格なセキュリティポリシーが有効になっているドメインによるピアドメインおよび/または上位レベルドメインへのセキュリティポリシーの適用を許可しない必要があります (してはならない)。

    例えば、bar.foo.example.comもfoo.example.comも、example.comに対してポリシーを設定できず (してはならず)、bar.foo.example.comはfoo.example.comに対してポリシーを設定できません (してはならない)。さらに、foo.example.comはsibling.example.comに対してポリシーを設定できません (してはならない)。

  7. UAは、ユーザーがセキュリティ警告を"クリックスルー"することを防ぐ必要があります (しなければならない)。セキュアトランスポートの例外に直面して接続の試みを停止することは許容されます。セクション12.1「No User Recourse」も参照してください。

注意 (NOTE): 本仕様は、上記の最初のコア要件を満たすために最初の接触を統一的に保護する方法を特に扱っていません（セクション14.6「Bootstrap MITM Vulnerability」を参照）。これは、本仕様の将来の改訂版または他の仕様で対処される可能性があります。また、UA実装が最初のコア要件をより完全に満たすことができるいくつかの方法があることに注意してください。セクション12「User Agent Implementation Advice」を参照してください。

2.4.1.2 Detailed Ancillary Requirements (詳細な付随的要件)​

これらの付随的要件も全体的な要件から派生します。これらは本仕様で規範的に扱われていませんが、実装者の裁量でUA実装によって満たすことができます。ただし、これらを満たすことは複雑である可能性があります。

  1. "混合セキュリティコンテキスト"読み込みを許可しない（セクション2.3.1.3を参照）。

  2. サイトがHSTSポリシーを通知するかどうかに関係なく、ユーザーによる厳格なセキュリティポリシーが有効になっているウェブサイトの宣言を容易にする。

に最終更新