Man in the Middle Attackを使用したJavaScriptインジェクション

Question

悪意のある攻撃者がホストするwifiホットスポットに接続しているとします。さらに、安全でないHTTP接続で架空の電子メールサイトtmail.comのログインページにアクセスしているとします。

私の質問は、WiFiホットスポットを所有する攻撃者が、痕跡を残さずに悪意のあるJavaScriptコードを挿入することによって、私のパスワードをどのように盗むことができるのかということです。これにアクセスしても、URLはtmail.comのままですか、それとも変更されますか？攻撃者がどこで（アプリケーションレイヤー/ネットワークレイヤー）およびどのように（Webページをダウンロードするか、ネットワークレイヤーデータを変更する）変更を成功させるのですか？

私はこの質問を純粋に教育目的で行っています。私は好奇心旺盛で誰にも危害を加えるつもりはありません。

apsillers · Accepted Answer

ISP（ここではWiFiホットスポット）がページを配信します。もちろん、ISPがセキュリティ保護されていないトラフィックを読み取るのは簡単です。

diagram showing that the ISP reads unsecured credentials over the wire

資格情報の送信がHTTPSで保護されている（ISPがネットワークから直接それらを傍受できない）が、HTTPSログインページが保護されていないスクリプトhelper.jsをロードする場合を考えてみましょう。 ISPは、ブラウザにスクリプトを提供する前に、HTTPS以外のスクリプトに動作を挿入できます。たとえば、ISPは「このページが資格情報を送信するときに、それらのコピーをevil.example.com。に送信します」という指示を挿入できます。下の図は、保護された要求と応答を緑色と非保護で示しています他の色のリクエスト/レスポンス：

diagram showing that the ISP modifies the page content to contain a malicious script

ブラウザーがHTTP経由でhelper.jsを要求すると、悪意のあるISPは間違ったコンテンツを持つリソースで応答します。お使いのブラウザーはhelper.jsがどのように見えるかを理解しておらず、整合性検証手段（HTTPSなど）がなければ、ブラウザーは何も問題がないとは考えていません。これはブラウザがhttp://tmail.com/helper.jsを正しく処理したことを前提としているため、ブラウザはそれを要求し、ISPはクレームなしで応答を返しました（たとえば、応答は200のHTTP /helper.jsでした）。 あなたのブラウザが得たものが実際のサーバが送ったものとは異なるという事実は全く無関係です、なぜならあなたのブラウザはそうすることができないからですこの違いが発生したことを検出します。

コメントに基づいて、リソースの変更はブラウザを別のリソースにリダイレクトすることによってのみ実行できると考えているようです。これは誤りです。 Bobブラウザー、Iggy ISP、および2つのサーバーAliceおよびMalloryを検討してください。

まず、正直なケースを考えてみましょう：

ボブはアリスの好きな食べ物を知りたがっています。
- ボブはイギーに、「ねえ、イギー、GET /favoritefoodをalice.comに送ってください。」と言います。
- イギーはアリスに自分の好きな食べ物について尋ねます。アリスは彼に、「ピザですが、玉ねぎはありません。玉ねぎが嫌いだからです。」
- イギーはボブに戻ってきて、「ねえ、GET /favoritefoodからのalice.comに対する応答があります。玉ねぎではなくピザが好きだと言っています」と言います。

今度は不正なケースを考えてみましょう：

ボブはアリスの好きな食べ物を知りたがっています。
- ボブはイギーに、「ねえ、イギー、GET /favoritefoodをalice.comに送ってください。」と言います。
- イギーはボブに戻り、「301 Moved Permanently-代わりにアリスの好きな食べ物についてマロリーに尋ねてください」と言います。
- その後、ボブはIggyをGET /favoritefoodからmallory.comに送信します。それは別のリソースであり、ボブは彼が最初に要求したものとは別のリソースであることを知っています。

この場合、ブラウザのアドレスバーは、最初に入力したものとは異なります：mallory.com/favoritefoodではなくalice.com/favoritefood。

代わりにこのケースを考えてみましょう：

ボブはアリスの好きな食べ物を知りたがっています。
- ボブはイギーに、「ねえ、イギー、GET /favoritefoodをalice.comに送ってください。」と言います。
- イギーはアリスに自分の好きな食べ物について尋ねます。アリスは彼に、「ピザですが、玉ねぎはありません。玉ねぎが嫌いだからです。」
- イギーはボブに戻ってきて、「ねえ、GET /favoritefoodからのalice.comに対する応答があります。たくさんの玉ねぎを食べるのが大好きだと言っています。」

関係する他のリソースはありません。 http://alice.com/favoritefoodは、ここでフェッチされる唯一のリソースです。 Iggyは単にリソースの内容が何であるかについて嘘をつきました。整合性検証システムがないため、ボギーがイギーが嘘をついていることを検出する方法はありません。

説明の最後の1つの試み： ISPは正直ですが、HTMLファイルのコンテンツを配信するときに誤って1ビットを反転させたとします。確かに、そのような間違いが原因で、Webページが別のドメインでロードされることはないと思います。次に、正直なISPが1ビットではなく2ビットを誤って反転させたとします。この場合も、このようなミスによってドメインまたはリソースパスが変更されることはありません。ここで、ISPが正直な間違いによって2,000ビットをフリップしたとします（おそらく、ISPのどこかに欠陥のあるスイッチがあるか、WiFiルーターが宇宙線の影響を受けた可能性があります）。ここでも、ドメインを変更する必要はありません。ここで、変更が誤ってではなく悪意を持って行われたと想定します。ここでも、意図の変更によって、実際に起こっていることに変化はありません。ブラウザのアドレスバーで識別されるリソースパスとオリジンは変更されないままですが、ISPは検出せずにリソースの内容を（正直または不正に）自由に変更できます。

PiTheNumber · Answer

Tmail.comのログインフォームはhttpsで送信されると思います。それ以外の場合は、パケットインスペクタでプレーンパスワードを読み取ることができます。

ブラウザがtmail.comからWebページをロードします。 wifiの所有者は、このページにJavaScriptを追加できます。このスクリプトは、メールプロバイダーのログインフォームに入力したものをすべて記録し、どこかに保存します。

これにアクセスしても、URLはtmail.comのままですか、それとも変更されますか？

はい、すべて同じに見えます。ただし、ページのソースコードには追加のJavaScriptが含まれています。

攻撃者がどこで（アプリケーションレイヤー/ネットワークレイヤー）およびどのように（Webページをダウンロードするか、ネットワークレイヤーデータを変更する）変更を成功させるのですか？

アプリケーション層では、彼はウェブページを変更します。

更新

よりよく理解するには、 mitmproxy.org を取得して replacement ツールを使用することをお勧めします。

:~q:</html>:<script>alert('hi')</script></html>

これにより、通過するすべてのHTMLページにJavaScriptが追加されます。