http://example.comからhttps://example.comへの最初のリダイレクトのセキュリティ

Question

http://example.com/<foo>が体系的にhttps://example.com/<foo>にリダイレクトするとします。ブラウザのURLバーにhttp://example.comと入力すると、ページが読み込まれ、URLバーにhttps://example.com/が正確に表示されます（Unicodeのハックや空白のハックなどはありません）。これが事実であることを確認します（ほとんどのユーザーはそうではありませんが、この場合はユーザーがそうであると想定しています）。さらに、私のブラウザーは RLバーの偽装に対して脆弱ではないと仮定します。また、SSL証明書が有効であると想定します。

この状況で、セッションがこれから中間者攻撃に対して脆弱ではないことを信頼できますか？最初のHTTP接続のMITMがsomething— cookie、隠しフレームなど、後続の見かけのHTTPSセッションを危険にさらすものを注入した可能性はありますか？

_{これは、ユーザーを http://normal.bank.com から https://secure.bank.com にリダイレクトする方法のサブケースです。この特定のケースの詳細。}

SilverlightFox · Accepted Answer

@GZBKと@Adnanの優れた回答と同様に、私が考えたもう1つのことは、アプリケーションが [〜＃〜] xss [〜＃〜] に対して脆弱であることです。 Cookieの値。

通常、Cookieの値はエンコードされていない状態で出力されますが、Cookieは通常HTTPS経由で設定され、MITMの対象にならないため、ユーザーが攻撃できるのは危険ではありません。ただし、HTTPリクエストがインターセプトされ、Cookieがこの脆弱性の悪用で汚染された場合 [〜＃〜] xss [〜＃〜] 脆弱性の場合、これはこのシナリオでの攻撃ベクトルの可能性があります。

もちろん、これは、「example.com」がポート80をまったくリッスンしていなくてもこのCookieが設定される可能性があるため、リダイレクトが脆弱であることを含むHTTPS以外のリクエストではありません。攻撃者は、被害者が作成した他のHTTPリクエストをMITMそれらを「http://example.com」にリダイレクトします。これも攻撃者が傍受し、ユーザーを元のWebサイトにリダイレクトするための応答を返しますが、「example.com」Cookieがポイズニングされた後でのみです。

これからの私のセッションが中間者攻撃に対して脆弱ではないことを信頼できますか？

信頼できないネットワークを参照するための本当に安全な唯一の方法は、HTTPS以外のブラウザーからすべてのプロトコルを無効にすることです（たとえば、ローカルプロキシを構成し、ブラウザーがHTTPS以外のすべてのプロトコルに無効なポートを使用するように設定します）。 HSTSは役立ちますが、最初のリクエストがインターセプトされた場合（たとえば、「example.com」にアクセスすることを考える前に、ここで説明されている手法を使用した場合）は依然として脆弱です。

コメント内の新しい質問に関連して以下を更新します：

[バウンティコメントを入力するのを忘れた]ユーザーの観点から質問している（サイト/アプリが何をすべきかを知ることも興味深い）。ブラウザーのURLバーにexample.comと入力すると、 https://example.com/ に直接移動できますか？ http://example.com/ と入力すると、どのような状況で https://example.com/ に直接アクセスできますか？最初に http://example.com/ へのリクエストがある場合、どのような問題が発生する可能性があり、ユーザーとしてどのようにして問題が発生しているかどうかを知ることができますか？ – Gilles

アクティブな [〜＃〜] hsts [〜＃〜] 「example.com」のレコードがあり（プリロードされているか、ユーザーが以前にアクセスしたことがある場合）、ユーザーが次のいずれかを入力した場合"example.com"または"http://example.com"のアドレスバーでは、HTTPでリクエストを行わずに直接"https://example.com"に移動します。

WebアプリケーションがユーザーエージェントにHSTSポリシーを発行すると、適合ユーザーエージェントは次のように動作します。Webアプリケーションを参照するすべての安全でないリンクを安全なリンクに自動的に変換します。（たとえば、 http://example.com/some/page/ は、サーバーにアクセスする前に https://example.com/some/page/ に変更されます。）接続のセキュリティを確保できない場合（サーバーのTLS証明書が自己署名されている場合など）は、エラーメッセージを表示し、ユーザーがWebアプリケーションにアクセスできないようにします。

[〜＃〜] hsts [〜＃〜] レコードがなく、ユーザーがアドレスバーに"example.com"または"http://example.com"と入力した場合、安全でないリクエストが最初に行われます「http://example.com」は通常「Location: https://example.com/」ヘッダーで応答します。これにより、ブラウザーはHTTPS URLをロードします。ユーザーが何も注入または変更されていないこと、および「Location」ヘッダーが返されたことだけが確認された場合、すべての状態情報をクリアする必要があります。これを行うプロセスは次のようになります。

他のすべてのブラウザウィンドウとタブを閉じます。これにより、他のHTTPリクエストがMITMされて「example.com」にリダイレクトされないようになります。
ブラウザでJavaScriptを無効にします。これにより、一定の間隔でCookieを設定するスクリプトが実行されていないことが保証されます。たとえば、Cookie値を通じて [〜＃〜] xss [〜＃〜] 脆弱性があった場合、挿入されたスクリプトは、数秒ごとにこれをリセットすることにより、Cookie値が設定されたままであることを保証できます。別名ゾンビクッキー。
Cookie、ローカルストレージ、ブラウザプラグインデータ（ローカルのFlash/Silverlightなど）をクリアします。これにより、サイトの状態情報のほとんどが削除されます。
ブラウザの更新を押します。これにより、現在のページのロードがPOSTではないことが保証されます。これは、ユーザーに警告メッセージが表示されるためです。POST任意 [〜＃〜] xss [〜＃〜] 脆弱性。
必要に応じてJavaScriptを再度有効にします。

明らかに、これは多くのことを経験し、前述のプロキシ手法を使用してHTTPを無効にし、クリーンなブラウザ（新しいシークレットセッションなど）で開始する方が簡単かもしれません。

ユーザーが信頼できないネットワークを参照している場合、100％安全になることはありません。すべてが既知の状態（したがって、クリーンな状態/ HTTPSから開始するか、すべての状態情報を削除する）でない限り、改ざんの簡単なチェックはありません。はい、手動でCookieをチェックできますが、スクリプトがページに埋め込まれると、攻撃者は巧妙な手法でCookieをクリアできます。

Adi · Answer

私が見る限り、ここには2つの脆弱性があります。

セキュアフラグが設定されていません。最初のHTTPリクエストは、http://example.comのインスタンスによって作成されたセッションから、またはhttps://example.comのインスタンスによって作成された前のセッションから、セッションCookieをリークします。同じリークセッション識別子が再利用されます->攻撃者はセッションにアクセスできます。
最初のHTTP要求がインターセプトされ、応答が攻撃者によって開始されたセッションのセッションIDを含むCookieを作成するものに置き換えられます。後続のリクエストは同じCookieを再利用します。これはセッション固定攻撃の形式です。

どちらの場合も、HTTPSインスタンスに到達すると、サーバーは前のセッションを無効にするかどうかを知る方法がありません。これは、セッションがユーザーによって開始された正当なものである可能性があるためです。

ここで私が目にする唯一の解決策は、https://example.comへのリクエストが行われたときにセッションを無効化して再作成し、その後のリクエストでセッションCookieに加えて暗号的に強力なトークンを使用することです。トークンは1回だけ使用する必要があります。

WhiteWinterWolf · Answer

上記のように、すべてのCookieにはセキュア（ Owasp ）のフラグを付ける必要がありますが、ユーザーがSSL経由でのみサイトにアクセスすることを期待する場合は、HTTP Strict Transport Security（HSTS-- ウィキペディア）。

1つ目は、クリアなHTTP接続でCookieが送信されないことを保証します。2つ目は、互換性のあるブラウザーが最初の最初のアクセス後、常にHTTPSを使用してWebサイトにアクセスするようにします（ユーザーがHTTPを入力した場合でも、ブラウザーはサーバーにHTTPリクエストを送信せずに、自動的にHTTPSに置き換えます）。

bizzyunderscore · Answer

最初のリクエストはHTTP経由で送信されたため、 Cookieやセッションの状態に依存せず、サーバーから提供されたHSTSヘッダーがあっても、HTTPSへのその後のリダイレクトの影響を受けない、利用可能な攻撃ベクトルが多数あります。

私はフルタイムのWebセキュリティスペシャリストではありませんが、攻撃者が元のHTTPリクエストをMITMできる場合に可能な攻撃のリストを以下に示します。

1）301/302リダイレクトを中間URLに送信して、ブラウザの外部でマルウェアをセットアップ/インストールします。これにはキーロガーなどが含まれる可能性があります。攻撃者は興味のあるサイトに行く犠牲者を「チェリーピック」できるため、非常に貴重です。マルウェアがターゲットに配備されると、最終的なブラウザーのリダイレクトが期待どおりにクライアントに送信され、映画は何も起こらなかったように続行します。

2）同じ車両を使用してブラウザ自体を攻撃します。攻撃者が悪意のあるプラグインのインストールなどのブラウザ固有のアクションを実行する機会があります。

3）上記と同様ですが、ブラウザの設定を変更するために利用可能なホールを利用します。これは、検索のヒントやキーワードの補完などの隠れチャネルを介した情報漏洩を可能にするために使用できます。または、これをオプション1と組み合わせて、ローカルで実行されるコードを介してSSLをプロキシするようにブラウザを設定します。

4）ターゲットSSLページをiframeにロードし、XSSの弱点を悪用して、被害者がログインするとセッション資格情報を取得して悪用します。

上記のシナリオにはさまざまな問題があり、それらはすべて特定のブラウザーバージョンの弱点に依存しています。シナリオの多くは、他の簡単な攻撃ベクトルよりも難しい場合があります。ユーザーエージェントのように、元のリクエストのヘッダーにある利用可能な情報に応じて、焦点を絞ったエクスプロイトを使用することには、魅力的な可能性があるユーティリティがあります。

私が見逃している攻撃には他にも幅広いカテゴリがあると確信していますが、これは最初のHTTPからHTTPSへのセッションが開く可能性のある露出の始まりです。

pyramids · Answer

SSL接続が正しいドメインで確立されているという前提に基づいて（サーバーにもブラウザーにも脆弱性がないことを前提として）、ユーザーはSSL証明書と信頼されたルート証明書を介して、ロード元のページを確認しましたサーバーは改ざんされることなく到着しました。

私は次の落とし穴を見ます：

インターセプターがSSL証明書を偽造できる場合、中間者攻撃は明らかに可能です。したがって、それを共有した場合（CDNを使用したり、Webホスティングの悪意のある管理者を使用したり、キーの召喚状を認めることを法的に禁止されている同僚と共有したり）、これは実際に攻撃の可能性があります。最初に弱いキーを生成した場合にも発生する可能性があります（システムのエントロピーが低いか、壊れた乱数ジェネレータを使用していた可能性があります）。
ブラウザが信頼するように構成されているルートCAが1つも侵害されていない可能性があります。通常、その数は非常に多く、中間者がドメインに対して明らかに有効なSSL証明書を偽造するために必要な妥協は1つだけであることに注意してください。また、一部のユーザーはベンダー（Microsoftなど）に要求に応じて新しいルートCA証明書をプッシュし、理論的にはMicrosoft（またはCAのいずれか）の（合法？））サポートを説得することができます。もちろん、善良な人だけが企業に対してそれだけの力を持つことを願っています。
一見無関係な脆弱性であっても、バグではなく機能と呼ばれる可能性のあるものであっても、明らかに引数全体を無効にすることができます。中間者が最初にHTTP経由でWebページを配信し、ブラウザが全画面表示に切り替わると想像してください。次に、通常のブラウザウィンドウを模倣します。あなたの架空の賢いユーザーは、アドレスバーとそのコンテンツが、ブラウザのアドレスバーの精巧なエミュレーションにすぎないことに気付くでしょうか？