Appleは、たとえばiCloud.comでHSTSを使用するため、ブラウザーのアドレスバーから、またはリンクを介して保護されていないアドレスhttp://www.icloud.comにアクセスしようとするたびに、自動的にhttps://www.icloud.comにリダイレクトされます。 。 これは、認証なしでチャネル上で金融取引を実行する場合など、単純なエラーを防ぐ優れた機能です。
ここで何が間違っているのでしょうか？
さて、HSTS標準では、Webブラウザーは安全なバージョンへのリダイレクトを記憶し 、ユーザーが将来安全でない接続を確立しようとすると、ユーザーに代わってそれを自動的に実行する必要があると説明しています。 これに関する情報は、ユーザーのデバイスに保存されます。 また、サイト間トラッカーが読み取る「スーパークック」の作成に使用できます。
恒久的なクロスサイト識別子としてのHSTS（スーパーCookie）
サイトの訪問者を追跡しようとする攻撃者は、ユーザーのデバイスのHSTSキャッシュから少しの情報を使用できます。 たとえば、「HTTPSを介してこのドメインをダウンロードする」は1を表し、エントリがない場合は0を表します。特定の多数のドメイン（たとえば32以上）を登録し、制御されたサブセットからリソースのダウンロードを開始することにより、各サイト訪問者の一意の表現に十分なビットスペースを取得できます。
HSTSの作成者は、仕様のセクション14.9でこの可能性を認識しました（「HSTSポリシー記憶の創造的な操作」）。
... 1つまたは複数のHSTSコンピューターを制御するユーザーの場合、ドメイン名の情報をエンコードし、HSTSコンピューターをマークするときにこのようなユーザーエージェントにこの情報をキャッシュさせることができます。 この情報は、Webリソースを適切に構築およびロードし、ユーザーエージェントにエンコードされたドメイン名の要求を送信させることにより、他のコンピューターによって抽出できます。
最初にサイトにアクセスしたとき：
- 訪問者には、
8396804
などの乱数が割り当てられます。 - バイナリ値に変換されます（たとえば、
10000000001000000000000100
）。 - トラッカースクリプトは、httpsを介して制御されたドメインからサブリソースを要求します。1つの要求は追跡識別子の1ビットを要求します。
-
https://bit02.example.com
-
https://bit13.example.com
-
https://bit23.example.com
- ...など。
-
- サーバーは、各HTTPS要求にHSTS応答ヘッダーで応答し、Webブラウザーに値をキャッシュします。
- これで、ユーザーがHTTP経由でダウンロードを開始した場合でも、bit02.example.com、bit13.example.com、bit23.example.comのHTTPSバージョンをダウンロードすることが保証されます。
その後のWebサイトへのアクセス時：
- トラッカースクリプトは、2進数のビットに対応するHTTPを介して32の非表示ピクセルをロードします 。
- これらのビットの一部（この例ではbit02.example.com、bit13.example.comおよびbit23.example.com）はすでにHSTSからダウンロードされているため、自動的にHTTPSにリダイレクトされます 。
- トラッキングサーバーは、HTTPを介して要求するときに一方の画像を送信し、HTTPSを介して要求するときにもう一方の画像を送信します。
- 追跡スクリプトはさまざまな画像を認識し、それらを2進数のゼロ（HTTP）および1（HTTPS）に変換し、出来上がり-一意のバイナリ識別子が再作成され、今ではそれらがあなたを追跡しています！
このような攻撃に対する防御の試みは、セキュリティとプライバシーのバランスをとる必要があるため妨げられています。 不適切な保護は、重要なセキュリティメカニズムを同時に損なう危険性があります。
タスク
HSTSプライバシーリスクは 、理論的に定期的 にマスコミで 議論さ れています。 HSTSプロトコルの悪意のある悪用の証拠がないため、ブラウザ開発者は、サイトからのすべてのHSTS指示に素直に従うように注意していました。
最近、この理論的な攻撃が実際にSafariユーザーに対して使用されていることがわかりました。 そのため、Webトラフィックのセキュリティを維持しながら、スヌーピングから保護するバランスの取れたソリューションを開発しました。
アップルソリューション
HSTSエクスプロイトは2つのステップで構成されます。1）追跡識別子を作成します。 2）読み取り操作。 両方の段階で保護を確立することにしました。
保護1：HSTSインストールをホスト名またはTLD + 1のみに制限
トラッカーサイトは、ドメイン名の異なるレベルで番号をエンコードする長いURLを構築することに気付きました。
例：
https://aaaaaaaaaaaaaexample.com
https://aaaaaaaaaaaaexample.com
https://aaaaaaaaaaaexample.com
https://aaaaaaaaaaexample.com
https://aaaaaaaaaexample.com
https://aaaaaaaaexample.com
https://aaaaaaaexample.com
… ....
また、トラッカーサイトでは、次のような多数の関連ドメイン名が使用されていることにも気付きました。
https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
... ....
https://bit64.example.com
テレメトリでは、攻撃者が広範なサブドメインに対してHSTSを同時にインストールすることが示されています。 この方法でHSTSを使用すると通常の使用には対応しませんが、追跡が容易になるため、ネットワークスタックを変更して、ロードされたホスト名（例：https: //aaaaaaaaaaaaexample.com）またはTLD + 1（例：https：// example.com ）。
これにより、トラッカーが多数のHSTSビットを効果的に設定できなくなります。 代わりに、トラッキングIDのビットを個別に表す各ドメインに移動します。 同時に、コンテンツプロバイダーと広告主は、32以上のドメインへのリダイレクトによる遅延は受け入れられないと判断する場合があります。 また、WebKitはリダイレクトチェーンのサイズを制限します。これにより、攻撃者が遅延を許容できると判断した場合でも、識別子の最大ビット数が制限されます。
これにより、スーパークックのインストールの問題が解決されます。
保護2：ロックされたドメインからのサブリソース要求のHSTS状態を無視する
WebKitを変更して、HSTS状態を更新するリクエストが無視されるようになりました。安全でないサブリソースをダウンロードするリンクが、 Cookieがブロックされているドメイン（たとえば、不可視のトラッキングピクセル）から来る場合、ソースURLが使用されるだけです。 これは、スーパースタックHSTSのビット識別子がゼロのみで構成されるという事実につながります。
おわりに
内部回帰テスト中に公開されたソフトウェアの最終バージョンから収集されたテレメトリは、記載されている2つの保護により、サイトの保護を損なうことなくHSTSスーパークックの作成と読み取りが正常に防止されたことを示しています。 これらはベストプラクティスに沿っており、HSTSが提供する重要な安全対策を提供していると考えています。 最初の防御の詳細をRFC 6797（HSTS）の作成者と共有し、このメカニズムを標準の一部にするよう取り組んでいます。