web-dev-qa-db-ja.com

HTTPS接続でのHTTP Cookieのセキュリティモデルの意味

ユーザーがカスタムスクリプトのURLを提供し、URLをCookieに保存し、スクリプトを後続の応答に組み込むことができる機能が必要です。

もちろん、これはすぐにクロスサイトスクリプティング攻撃の可能性に対する懸念を引き起こしますが、中間者攻撃を実行しない限り、サードパーティがCookieを操作できないことを考えると、HTTPを使用します*。スクリプトをページに直接挿入する方が簡単です。これにより、サイトの整合性がさらに損なわれることはありません。

* Cookieは通常の同じOrigin規制に該当しないため、発信元ドメインのすべてのサブドメインのすべてのポートが信頼されていると想定

ただし、HTTPSを使用すると、通信の他の部分と同様に、適切な暗号化と認証を使用して、サーバーを介して間接的に設定するか、専用のユーザーエージェントインターフェースを介して直接設定することにより、ユーザーからのCookieを信頼できます。 、中間者のリスクを排除します。

ブラウザーは、セキュアチャネルを通じて設定されたCookieを安全でないチャネル（secure属性を使用）で送信しないように指示できますが、セキュアチャネル上の安全でないチャネルを通じて取得したCookieをすぐに送信するため、そうではありません。

したがって、たとえば、攻撃者がワイヤレスアクセスポイントを迂回してトラフィックを迂回させると、被害者をHTTP経由で特定のドメインのページをリクエストするように誘導する可能性があります（リンクをクリックする、画像などの埋め込みリソースを表示する、またはリダイレクトする）。偽造されたCookieで応答し、被害者にHTTPSを使用してサーバーと通信する際に偽造されたCookieを使用させる（悪意のあるスクリプトの挿入、セッションの修正など）。

これらすべてを考慮して、私はいくつかの質問があります：

  1. 上記の理解は正しいですか、また、HTTPSを介してクライアントと通信するサーバーは、すべてのCookieが危険にさらされていると考え、サイトのセキュリティを危険にさらさない方法でのみ使用する必要があります（信頼できる事前定義済みスクリプトの選択のみを許可し、セッションIDなど）？

  2. 考えられない安全な接続を使用しているときにCookieの整合性を確保するために利用可能なHTTPのフレームワークを考慮した方法はありますか？ （おそらく暗号化を使用していますか？）

  3. この問題を解決するために進行中の、聞いたことがない標準化の取り組みはありますか？そうでない場合、できる限り同じOriginポリシーを適用してユーザーに混合コンテンツのリスクを警告するブラウザーベンダーが、プロトコルのこの弱点に対処しないのはなぜですか？

tlshttpcookiessame-origin-policy
1
Joó Ádám

一般的に言って、サーバーはすべての着信データ要素を潜在的に敵対的であると見なします。ここで、「サイトの整合性」について話すとき、定義の問題があります。これは、ユーザーに表示されるサイトの整合性に関連する可能性があります、または他のユーザーが見るようなサイトの完全性。サーバーが行うすべてのことは、実行するスクリプトとして、それを言ったクライアントにCookieを送り返すことである場合、問題はより簡単です。

私が理解しているように、次のシナリオを恐れています。

  • このサイトでは、ユーザー[〜＃〜] u [〜＃〜]が一部のJavascriptをアップロードして、サーバーが「保存」し、同じユーザー[〜＃〜] u [〜＃〜]。このアップロードは、適切に保護されたプロセス（HTTPS、ユーザー認証...）を経由します。ストレージは実際にはサーバーで行われるのではなく、ユーザー自身のブラウザーのCookie値として行われます。

  • ユーザーの騙しやすさを悪用するか、ユーザーのネットワークアクセスをハイジャックすることにより、攻撃者は悪意のあるJavascriptをプッシュすることに成功します[〜＃〜] h [〜＃〜]サーバーの名前に（Cookie値として）接続されているユーザーのブラウザーに。

  • ユーザー[〜＃〜] u [〜＃〜]が次にサーバーに接続するときに、悪意のあるJavascript [〜＃〜] h [〜＃〜]がサーバーに（クーキーとして）送信され、サーバーはそれをクライアントに送信して実行します。

このように説明すると、問題は実際には、通常のプロセス（HTTPSとユーザー認証を使用）によってサーバーにプッシュされた「公式」のCookieを認識することです。 [〜＃〜] mac [〜＃〜] を使用すると、暗号化が役立ちます。Cookie値にタグを付けて、サーバーだけが適切なタグを計算して検証できるようにします。これにより、サーバーは、安全な登録プロセスで以前に記録されていないCookie値を拒否します。上記のシナリオでは、悪意のあるJavascript[〜＃〜] h [〜＃〜]の値には適切なMAC値がありません（攻撃者がサーバーが使用するMACキーを知っているため）、サーバーは実行するスクリプトとしてCookieの内容を送り返すことを拒否します。

一般的には、サーバーの状態をクライアントにオフロードすることです。これは次のようにして行うことができます：

  • 整合性を維持するためのMAC（Cookieを変更するクライアントに対して）
  • 状態の内容をユーザーに表示してはならない場合の暗号化（説明したとおり、これは特定のケースには適用されません）。

詳細については この質問 を参照してください。

個々のCookieのサイズ、および特定のサイトのブラウザーによって記録されたCookieの数は、両方とも ブラウザー固有の制限 の影響を受けることに注意してください。

2
Tom Leek

はい、あなたの理解は正しいです。

短い答え- HSTS Policy （HTTP Strict Transport Security）を設定します。これがブラウザーインスタンスごとに設定されると、ブラウザーによって作成されたプレーンHTTP接続はすべて自動的にHTTPSにアップグレードされます。

これは、HSTS HTTPヘッダーがHTTPS経由で受信された最初の訪問後にのみ有効になることに注意してください。ブラウザからの最初のアクセスの前にcookieを設定する攻撃から保護するために、ドメインを HSTS Preload にリストするように申請できます。このリストは主要なブラウザベンダーによるビルドに含まれており、プリロードされたドメインでHSTSを有効にするためにドメインに初めてアクセスする必要はありません。

HSTSプリロードを使用すると、サイトのすべてのサブドメインでHTTPSを使用する必要があります。これは、ドメインの場合、Cookieの同一生成元ポリシーがそれほど厳密ではないため、とにかく良い方法です。

上記のアプローチは 中間者がプレーンなHTTPリクエストをインターセプトしてドメインにリダイレクトすることによりサイトにCookieを挿入することを防ぎ、サブドメイン攻撃を防ぎます 。

HSTSの流れ

プリロードなし

First HTTP visit --> Server redirects to HTTPS --> HSTS Set
--> Cookie containing JavaScript set

Next HTTP Visit | browser upgrades to HTTPS --> Safe JavaScript in cookie runs

HSTSプリロードあり

First HTTP visit | browser upgrades to HTTPS --> ...

MITM攻撃によってユーザーをリダイレクトする攻撃者

HSTSなし

User requests a plain HTTP site --> HTTP 3xx redirect to your site --> Evil cookie set over plain HTTP
User requests your site over HTTP --> Server redirects to HTTPS --> Malicious JavaScript is ran

HSTSを使用

User requests a plain HTTP site --> HTTP 3xx redirect to your site | browser upgrades connection to HTTPS --> Attack thwarted as attacker cannot MITM the HTTPS connection

セキュアCookieを使用しても、サーバーはセキュアフラグが設定されているという事実を照会できません。サーバーが取得するのは名前と値のペアだけです。したがって、Cookieが汚染されていることを知る方法はありません。 HSTSは、安全でないプレーンなHTTPチャネルを遮断するため、効果的なソリューションです。

質問では、URLは直接のJavaScriptではなくCookieに保存されると述べていますが、サードパーティのドメインからのJSコードを含めてもまったく同じ効果があります-コードは要求元ドメインのオリジンで実行されます

プレーンHTTPサポートが必要な場合

HSTSが必要な理由は、 Cookieの同じ生成元ポリシー がDOMのポリシーよりも緩慢であり、AJAXリクエスト中：

cookieのスコープメカニズムはより広く、基本的には同じ元のポリシールールと互換性がありません（たとえば、前述のように、Cookieを特定のホストまたはプロトコルに制限する機能はありません）。 。

したがって、JSコードを含むCookieを安全に保護する唯一の方法は、完全に異なるドメインでのみプレーンなHTTPサポートを提供することです。例えばhttps://example.org安全なコンテンツとCookieのためのHTTPSとHSTS、およびhttp://example.com非セキュアコンテンツ用。

クッキーの代替

上記を実行できない場合、なぜCookieの代わりに HTML5 Session Storage を使用せず、HTTPS経由でのみ値を設定または読み取りますか？このメソッドを使用すると、MITMがプレーンHTTPを介して値をインターセプトおよび変更する可能性なしに、JavaScript URLをブラウザーに格納し、必要に応じて実行することができます。

分離とは、 http://htmlui.com でLocalStorageに保存された値が、 https://htmlui.com から提供されるページからアクセスできないこと（およびその逆）を意味します。 [*]

2
SilverlightFox