HTTPへのダウングレードと混在コンテンツのリスク

HTTP Strict Transport Security（HSTS）ヘッダーは、指定した期間、ブラウザーにサイトへの接続をHTTPS経由に限定するよう指示します。HSTSを受信すると、ブラウザーはHTTP接続を拒否し、http:// URLを自動的にhttps://へアップグレードします。

典型的なHSTSヘッダーは、"Strict-Transport-Security: max-age=31536000; includeSubDomains; preload"です。max-ageは秒単位で指定します（31536000 = 1年）。いったんキャッシュされると、ブラウザーはサーバーの関与なしに1年間HTTPSを強制します。

max-ageパラメーターは、ブラウザーがHTTPSのみの接続を強制する期間を秒単位で設定します。本番サイトでは、少なくとも1年（31536000）にすることが推奨されます。

includeSubDomainsディレクティブは、HSTSの適用範囲をすべてのサブドメインに拡張します。これにより、攻撃者がサブドメインの接続をHTTPにダウングレードし、メインドメインでSecureフラグなしに設定されたCookieを盗む攻撃を防ぎます。

ブラウザーには、初回のアクセスであっても常にHTTPSのみを使用するドメインのハードコードされたリストが組み込まれています。hstspreload.orgで管理されているこのリストには、数千の主要Webサイトが含まれています。

プリロードにより、初回アクセス時の脆弱性がなくなります。プリロードがなければ、初めて訪問したユーザーはHSTSヘッダーを受信する前に傍受される可能性があります。プリロードされたサイトは、HSTSのキャッシュ状態に関係なく、最初のリクエストからHTTPSのみになります。

SSLストリッピングは、Black Hat 2009でMoxie Marlinspikeが発表した、HTTPS接続をHTTPにダウングレードするMITM攻撃です。攻撃者はユーザーの最初のHTTPリクエストを傍受し、ユーザーに代わって実際のサーバーへHTTPSリクエストを送り、コンテンツをHTTP経由でユーザーに転送します。

被害者には通常どおりコンテンツが表示されますが、接続はHTTPです。入力した認証情報は攻撃者に送られます。HSTSが登場する前は、ユーザーが南京錠アイコンの欠落に気付かなかったため、この攻撃は非常に効果的でした。

HSTSは、ブラウザーがHSTSに登録されたドメインへのHTTP接続を拒否するため、SSLストリッピングを防ぎます。攻撃者がHTTPでページを提供しようとしても、ブラウザーは接続を拒否してエラーを表示します。

ブラウザーによるHSTSの適用はネットワークリクエストより前に行われるため、攻撃者は介入できません。残る脆弱性は、HSTSを受信する前の初回アクセスだけですが、プリロードによってこの脆弱性もなくなります。

混在コンテンツとは、HTTPSページがHTTP経由でリソースを読み込む状態です。パッシブ混在コンテンツには、HTTP経由で読み込まれる画像、音声、動画が含まれます。これらはページを直接変更できませんが、HTTPヘッダーを通じてユーザー情報を漏えいさせたり、追跡を可能にしたりします。

アクティブ混在コンテンツには、HTTP経由で読み込まれるスクリプト、スタイルシート、iframe、XMLHttpRequestsが含まれます。HTTP経由のスクリプトはDOMに完全にアクセスでき、Cookieやフォームデータを読み取れるため、HTTPSページのセキュリティを完全に侵害する可能性があります。

最新のブラウザーは、外側のページがHTTPSの場合、アクティブ混在コンテンツ（HTTP経由のスクリプト、スタイルシート、iframe）をデフォルトでブロックします。コンソールにエラーが表示され、リソースは読み込まれません。

Chrome 81（2020）以降、ブラウザーはパッシブ混在コンテンツをHTTPSへ自動的にアップグレードするようになりました。HTTPS版が存在する場合は、それが読み込まれます。存在しない場合、リソースはブロックされます。

ブラウザーの開発者コンソールには、混在コンテンツに関する警告とエラーが表示されます。ChromeではDevToolsを開き、Consoleタブに移動して、"Mixed Content"でフィルタリングします。ブロックされた各リソースには、更新が必要な安全でないURLが表示されます。

DevToolsのSecurityパネルには、証明書の詳細、接続情報、ページ上のすべての安全でないリソースの一覧など、包括的なセキュリティ概要が表示されます。

Content Security Policy（CSP）の"upgrade-insecure-requests"ディレクティブは、ページからのすべてのHTTPリクエストをHTTPSへ自動的にアップグレードするようブラウザーに指示します。これにより、HTTP URLがハードコードされたレガシーコンテンツにも対応できます。

混在コンテンツをブロックする場合とは異なり、upgrade-insecure-requestsはまずHTTPS版の取得を試みます。レガシーコンテンツに埋め込まれたすべてのURLを更新するのが現実的でない場合に、HTTPからHTTPSへ移行する際に役立ちます。

HTTPSを使用しない場合、ISPはHTTPレスポンスにコンテンツを挿入できます。複数のISPが、広告のないWebページに広告を挿入したり、トラッキングピクセルを追加したり、ユーザーがデータ上限に近づいたときに警告ページを挿入したりしていたことが発覚しています。

このようなコンテンツの挿入は、HTTPSページでは不可能です。レスポンスは認証および暗号化されているため、変更するとTLS MAC検証に失敗し、変更されたコンテンツが提供されるのではなく接続エラーになります。

ブラウザーがドメインのHSTSヘッダーをまだ受信していない場合、HTTPによる最初のアクセスは脆弱です。攻撃者はこの最初のリクエストを傍受し、ブラウザーに警告を表示させずにSSLストリッピングを実行できます。

この「初回使用時の信頼（trust on first use）」の脆弱性が、HSTSプリロードリストが存在する理由です。サイトをプリロードリストに登録すると、ブラウザーは最初のリクエストからそのドメインにHTTPSを適用し、初回アクセス時の隙を完全になくせます。

HTTP Strict Transport Securityについての理解度を確認しましょう。

HSTSは、指定した期間、ブラウザーにドメインへのHTTPSのみの接続を強制します。プリロードリストは、ブラウザーにHSTSポリシーをハードコードすることで、初回アクセスから保護します。

SSLストリッピング（Moxie Marlinspike、2009年）はHTTPSをHTTPにダウングレードしますが、HSTSはこれを防ぎます。アクティブ混在コンテンツ（HTTPSページ上のHTTPスクリプト）はブラウザーによってブロックされます。upgrade-insecure-requests CSPディレクティブは、レガシーコンテンツのHTTPからHTTPSへの移行を自動化します。