MITMはX-Frame-Optionを操作できますか
次のシナリオが現実的に実現可能かどうか疑問に思いました。
ボブが使用するコンピューターとのネットワークがあります。彼はセキュリティに敏感な人で、パスワードマネージャーを使用しています。彼のコンピューターは、ボブがISPから入手したルーターを介してインターネットに接続されています。 ISPとルーターの製造元は、ルーターが持つ重大な脆弱性の更新を展開していません。
それから、ボブのパスワードを本当に知りたがっているトゥルーディがいます。彼女はエクスプロイトを通じて彼のルーターへのフルアクセスを取得します。彼女が興味を持っているWebサイトがいくつかあるので、彼女はDNSエントリを操作して、自分の管理下にあるWebサーバーをポイントします。 Trudyには多くの時間がかかるため、BobのコンピューターのDNSキャッシュは、操作されたエントリを含むように最終的に更新されると想定されています。
ボブはたまたまトルディが興味を持っているウェブサイトに接続しています。彼はhttps://www.safewebsite.comとの接続を確立していると思っていますが、実際にはトルディのウェブサーバーに接続しています。 Webサーバーは、接続を確立するためだけに、接続をプレーンhttpにダウングレードします。次に、ウェブサーバーはそれ自体の実際のURLへのリダイレクトを実行します。 Trudyが有効な（単純な）SSL証明書を持っているhttps://safewebsite.evil.com。ボブがあまり詳しく見ていないと仮定すると、アドレスバーに違いは見られません。
または、Trudyは、無効な証明書の例外をトリガーしない方法で、BobにWebサーバーにアクセスさせます。
ボブのパスワードを抽出するためにTrudyが行う必要があるのは、ボブがアクセスしたい有効なWebサイトを埋め込むことです。 Trudyは、フィッシングWebサイトをコーディングしたくないが、Bobのパスワードマネージャーをだまそうとしているため、これはたまたま作業が少なくなります。ボブがTrudyの悪意のあるWebサイトにアクセスすると、パスワードマネージャーは、これが有効な接続であると信じているため、埋め込みWebサイトに資格情報を入力します。次に、TrudyのWebサイトのスクリプトが、パスワードフィールドとユーザー名の内容を取得し、両方をWebサーバーに送信します。
現在、Trudyには苦労していることがあります。多くのウェブサイトでは、x-frame-optionが拒否に設定されています。これは多くの場合、Trudyの試みを失敗させます。彼女は、ルーターにx-frame-optionを含むパケットをスニッフィングさせるという考えを持っています。その後、変更または削除されます。したがって、ボブがTrudyの悪意のあるWebサイトにアクセスすると、埋め込まれた実際のWebサイトを要求し、ルーターはアクティブなMITMを実行します。これは、ルーターがhttps://www.safewebsite.comに接続し、ボブにhttpバージョンのみを渡すことを意味します。ボブはまだhttps://safewebsite.evil.comを表示し、以前のバージョンの攻撃と比較して視覚的な変化を示していません。問題は、ルーターがボブのブラウジング体験に影響を与えない方法でx-frame-optionを削除または変更できるかどうかです。
うまくいけば、アイデアは明確です。非現実的なものを見つけた場合は、コメントを残してください。たぶんあなたはこれを達成する方法についてさらに簡単な考えを持っています。
これは、大学のコースのプレゼンテーションで使用したい特定のパスワードマネージャー（ここでは名前を付けません）に対する攻撃シナリオですが、それがもっともらしい場合に限ります。
更新
これを何度か知って考えてきましたが、上記のアイデアには重大な欠陥があります。www.safewebsite.comをhttpsとしてロードする必要があります。そうしないと、パスワードマネージャーがデータを入力しません。シナリオに取り組み、更新されたバージョンを投稿します。
アップデート2
パスワードマネージャーには、資格情報をiframeに入力する際のセキュリティ上の問題があるようです。ただし、シナリオには欠陥があり、与えられた回答は元の質問に対して正しいものです。新しいシナリオが機能する場合は、最初に開発者に連絡し、後で問題に関する詳細情報を公開します。
HTTPを介して、MITMは任意の要求ヘッダーを操作できます。
HTTPSを介して、MITMは、有効な証明書を持っていないか、ボブのブラウザで証明書の警告を生成しない限り、これを行うことはできません。
www.safewebsite.comは、HSTSを使用することで、この攻撃の一部を軽減できます。HSTSは、ボブのブラウザに、最初の接続後にのみSSL経由でアクセスするように指示します。このサイトは、HTTPを介したPOSTリクエストを拒否することもできます（ただし、Bobのブラウザによるリクエストの送信を停止することはありません）。
3つのことが当てはまる場合、攻撃は機能します。
1：パスワードマネージャーは、ログインフォームページのhttps/httpをチェックしません。 （または、フォームが実際にはHTTPS接続を介してPOSTされたHTTPフォームであること）
2：パスワードマネージャーは、認証/トリガーURLとしてトップフレームURL（表示URL）を使用しません。
3：パスワードマネージャーは詳細を直接送信しませんが、代わりに入力します。 （一部のパスワードマネージャーは、視覚的にそのように見えても、画面に詳細を入力する代わりに、フォームを直接POST「コピー」します-一部のパスワードマネージャーは、南京錠のアイコンでこれを示しますユーザー名/パスワードフィールドの右側。captchaやCSRFトークンなどの他のフィールドは、パスワードマネージャーに送信されてPOSTに含まれます。これは、キーロガーを防止するためのセキュリティ機能です。 -攻撃の例を提供したように-フレームから詳細を取得するフレームグラバー）
ただし、あなたが話しているダウングレード攻撃はもちろんHTTPS警告をトリガーします。攻撃をダウングレードする唯一の方法は、クライアントが最初にHTTPリソースにアクセスしている場合であり、リンクまたはフォームのHTTPSを取り除くことができます。ユーザーがHTTPS警告をクリックすることを期待するか、safewebsiteへのHTTPS接続をブロックして、ユーザーが「HTTP」を試して問題が解決するかどうかを確認することができます。
X-Frame-Optionのストリッピングのためではなく、次の理由により、攻撃が実行可能であるとは思えません。
ボブがTrudyの悪意のあるWebサイトにアクセスすると、パスワードマネージャーは、これが有効な接続であると信じているため、埋め込みWebサイトに資格情報を入力します。次に、TrudyのWebサイトのスクリプトが、パスワードフィールドとユーザー名の内容を取得し、両方をWebサーバーに送信します。
「埋め込む」とは、<iframe>を置くことを意味すると思いますか？では、TrudyのWebサイトのスクリプトは、パスワードフィールドのコンテンツをどのように取得するのでしょうか。同一生成元ポリシーは、入力されたパスワードフィールドを含む<iframe>のコンテンツをスクリプトが読み取ることを禁止します。