SSLStripについて学んだところです。ゲームにとても遅れているように感じます。私が知りたいのは、サイトがHTTPSを介してのみコンテンツを提供し、リダイレクトなしでHTTPリクエストでハードに失敗する場合でも、まだ脆弱ですか?ブラウザのアドレスバーに入力した場合、攻撃者はHTTPSリクエストを傍受し、いわゆる「あなたに代わって」リクエストを実行し、ブラウザにHTTPバージョンを提供できますか? (SSLStripまたは他の攻撃を使用していますか?)
TL:DR;
以下にuser10008が答えを示します。 SSLStripはサーバーの動作に依存せず、クライアントに依存します。クライアントがHTTPSではなくHTTP経由でリクエストを行うことができる場合、サーバーがHTTPSのみをサポートしている場合でも、攻撃を実行できます。 HSTSは、ブラウザーがそもそも(後続の要求に対して)プレーンHTTP要求を実行するのを防ぎます。
はい、追加の対策を講じなくても、攻撃者は引き続きSSLStripを実行できます。SSLStripが機能するためには、攻撃者は中間者であり、HTTPに関するユーザーの行動とは無関係である必要があります。着信HTTPリクエストで、攻撃者は実サーバーへのHTTPS接続を開き、SSLをHTTPSから「ストリップ」します。したがって、攻撃者とサーバーの間にはHTTP通信はありません。サーバーのHTTP動作が無関係であると思われる場合でも、さらなる緩和策としてHTTPを無効にするか、永続的なリダイレクトを作成することをお勧めします。
HTTPSのみを提供し、将来的にHTTPSが必要になると確信している場合、 HTTP Strict Transport Security(HSTS) を使用して部分的に軽減することができますHTTPSのみを提供することをユーザーに伝えます。これにより、攻撃を受けることなく少なくとも1回接続した時点から、すべてのユーザーのSSLStripが軽減されます。
Firefoxの完全な緩和策を実現するには、ChromeをリクエストしてHSTSに自分を追加する whitelist。Firefoxと= ChromeホワイトリストのWebサイトでのHTTPSの使用を前提としていますが、そのリストに含まれるための要件はHSTSヘッダーを送信することです。適用の詳細については こちら をご覧ください。
サイトがHTTPSを介してのみコンテンツを提供し、リダイレクトなしでHTTPリクエストでハードに失敗する場合でも、まだ脆弱ですか?
ユーザーが誤ってhttp://example.com
ではなくhttps://example.com
をアドレスバーに入力した場合でも、sslstripは接続を傍受してユーザーをだますことができます。
これは、ユーザーの次の悪意のあるリンクにも当てはまる可能性があります。ユーザーがアドレスバーにパドロックがないことに気付かない場合は、脆弱である可能性があります。
HTTP Strict Transport Security ヘッダーを送信する場合、これはユーザーがその特定のインスタンスを使用してHTTPS経由でサイトに以前にアクセスしたことがある場合、またはブラウザーのベンダーにそのベンダーを要求した場合にのみ保護できます。 HSTSプリロードリストにサイトを含めます。 IEはまだHSTSをサポートしていない であることに注意してください。
あなたが cookieを安全であるとマークする でない限り、攻撃者は被害者からの他のHTTPリクエストをMITMし、安全でないバージョンのサイトにリクエストを挿入できる可能性があります(例:<img src="http://example.com/mitm.jpg" />
を使用すると、サイトのCookieをMITMで使用できるようになります。HSTSもこれを防ぐことに注意してください。
また、 サイトにCookie値のレンダリングによるXSSの脆弱性がある場合、攻撃者がMITM攻撃を使用して悪意のあるスクリプトをここに挿入する可能性があります HSTSがアクティブでない場合。これは、安全なCookieを設定している場合でも可能です。サーバーは、Cookieを読み取るときに安全なCookieを区別できないため(値を取得するだけです)、攻撃者がMITM攻撃中にHTTP接続を介して何かを操作したかどうかはわかりません。サーバー。
上記でかなりの範囲をカバーし、あなたが尋ねたことを拡張しましたが、これらはサーバー側でプレーンHTTPをリッスンしていなくても使用できるすべてのタイプの攻撃です。
攻撃者がHTTPSリクエストを傍受し、いわゆる「あなたに代わって」リクエストを実行して、いわば、ブラウザにHTTPバージョンを提供できますか
(ブックマークなどから)HTTPSサイトに直接アクセスする場合、SSLStrip MITM攻撃はほとんどありません。ブラウザがTLSハンドシェイクを探しているためにリクエストが失敗するか、攻撃者が偽の証明書を使用している場合は証明書エラーを表示します。
これをサーバー側で実行している場合、このリダイレクトが傍受される可能性があるため、HTTPをHTTPSにリダイレクトするために常にサーバーに依存することはできません。
また、暗号化されていないソースからハイパーリンクを介してページにアクセスすると、SSLStripに対しても脆弱になります。あなたの質問がこれらの最後の2つの状況について具体的に尋ねたのではないことを知っていますが、私はそれらを徹底的に言及したかっただけです。 HSTSを使用して、後者の攻撃を緩和する方法があります。
[〜#〜] hsts [〜#〜] を使用すると、サーバーはWebクライアントにHTTPSのみを使用するように指示します。サイトへの最初の要求が変更されずに行われる限り、サイトへの以降のすべての訪問はSSL/TLSの使用を強制されます。これは、https://
がhttp://
に変更されたとしても、ブラウザーがhttps://
のみを使用することを認識しているため、SSLStripが安全でないWebサイトからのハイパーリンクで機能しないようにするために機能します。
攻撃の一部は、被害者のすべてのTCP/UDPトラフィックに対してMITMを実行しているため、ユーザーがhttpsアドレスを明示的に使用しない限り、騙される可能性があります。
例:被害者が「mail.google.com」にアクセスしようとし、Googleがhttpからhttpsに自動リダイレクトすることを信頼している場合(自分で試してみてください)、アドレスバーにキーロックアイコンが表示されていないことを確認しない/緑bar /何でも、すでにMITMを実行した攻撃者は、そのサイトからのすべてのトラフィックをクリアテキストで取得します。
それにもかかわらず、クライアントが以前に少なくとも1回HTTPSへの接続に成功した場合(および最新のWebを使用した場合)に、このような攻撃を受ける可能性を最小限に抑えるように設計されたすべてのサーバー応答に含めることができる新しいHTTPヘッダーがあります。それをサポートするブラウザ):
厳格な輸送セキュリティ
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
Apacheサーバーがすべての応答にこのヘッダーを含める場合:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
注:WebのHTTPバージョンとHTTPSバージョンの両方を持っている場合、クライアントがサーバーからそのヘッダーを取得するとすぐに、彼はできなくなりますHTTPバージョンに接続する(Cookieを消去するか、別のブラウザーを使用するか、(おそらく)プライベートナビゲーションを使用するまで)