リクエストまたはレスポンスがハッキングされた場合にブラウザが悪意のあるコンテンツをレンダリングしないようにするにはどうすればよいですか？

Question

現在、OWASPのセキュリティ修正に取り組んでおり、考えられる解決策を見つけようとしている1つの攻撃シナリオを特定しました。

ユーザーがアプリケーションに対して有効なHTTPRequestをヒットしました。ユーザーのブラウザのURLは、アプリケーションのURLに設定されています。 https//www.abc.com/request
これらのいずれか：
- A：攻撃者はリクエストを傍受し、アプリケーションではなく悪意のあるサイトに転送します。ユーザーのブラウザのURLは、アプリケーションのURLに設定されています。 https://www.abc.com/requestただし、コンテンツは悪意のあるサイトのコンテンツになります。
- B：アプリケーションは要求を処理し、Apacheを介して応答をディスパッチします。応答が途中である間、攻撃者は応答を傍受し、応答全体のコンテンツを「You AreHacked !!」のような悪意のあるサイトまたはメッセージに置き換えます。
いずれの場合も、応答はユーザーのブラウザに表示され、URLはブラウザのhttps://www.abc.com/requestを指していますが、コンテンツは悪意のあるものです。これにより、ユーザーはそれがまだアプリケーションにあると信じ込ませます。

このシナリオは、プロキシツールを使用して複製できます。 HTTPSであるため、攻撃者は応答を解読できない可能性がありますが、応答の内容を変更したり、悪意のあるサイトにリダイレクトしたりすることはできます。 ApacheまたはカスタムHTTPヘッダーを介して、ブラウザーでそのような応答を識別してレンダリングしないようにする方法はありますか？

シナリオ（2A）で、ユーザーが有効なHTTPSサイトから悪意のあるHTTPサイトにルーティングされた場合はどうなりますか？

SilverlightFox · Accepted Answer

ドメインへのリクエストがHTTPS（例：https://example.com）の場合、これはMITM攻撃者の影響を受けません（企業プロキシの問題は別として）。攻撃者がexample.comを自分のサイトのIPにリダイレクトした場合、自分のサイトにはexample.comの信頼できる証明書がインストールされないため、ユーザーはブラウザの警告を受け取り、証明書を受け入れることを強くお勧めしません。サイトを閲覧する。

攻撃者がこれを回避する唯一の方法は、秘密鍵を使用して証明書のコピーを取得するか、ドメインに対して独自の信頼できる証明書を取得することです。これは非常に困難です。そして、彼らがあなたのサーバーに侵入することによってこれを行うことができれば、とにかく彼らは勝ちます。結論 X.509の公開鍵インフラストラクチャを信頼します。これがどのように機能するかについての詳細は、そこを読んでください。

guesticle · Answer

HTTPSは、あなたが説明する中間者（MITM）攻撃に対する防御です。

Httpsであるため、攻撃者は応答を解読できない可能性がありますが、応答の内容を変更したり、悪意のあるサイトにリダイレクトしたりすることはできます。

ブラウザがhttps応答を期待しているときに、MITMがどのように応答を変更できるかわかりません。攻撃者がhttpにダウングレードすることを心配している場合は、 [〜＃〜] hsts [〜＃〜] （HTTP Strict Transport Security）を検討する必要があります。 HSTSプリロードリストに追加して、最初の接続がダウングレードされないようにすることもできます。

sslstrip 攻撃またはこれ関連する回答について読みたいと思うかもしれません

CBHacking · Answer

受け入れられた答えはすでに重要な点をカバーしていますが、私があなたが解決するのを手伝いたい他のいくつかの誤解があるようです。

このシナリオは、プロキシツールを使用して複製できます。

プロジー（Fiddler、Burp、ZAPなど）を介してHTTPS応答を変更できる場合は、ブラウザーのルート証明書をコンピューターにインストールするか、サイトの信頼できないHTTPS証明書に対するブラウザーの異議を無効にする必要があります。潜在的な被害者が最初に行うことはなく、2番目に行う可能性は低いです。

HTTPSであるため、攻撃者は応答を解読できない可能性がありますが、応答の内容を変更したり、悪意のあるサイトにリダイレクトしたりすることはできます。

いいえ、TLS（HTTPとHTTPSを区別するセキュリティプロトコル）もそれを防ぎます。 TLSは、暗号化（要求と応答の機密性）だけではありません。特に、以下も提供します。

認証（特にHTTPSで使用されることはめったにありませんが、話していると思われるサーバーと話していることを確認し、オプションでサーバーがクライアントのIDを確認できるようにします）。
整合性（攻撃者が要求または応答のいずれかを変更するのを防ぎます。変更された要求または応答は、追加のデータを追加したり、1ビットを反転したりするだけでも、すべてのTLSメッセージが持つ暗号認証タグと変更されたメッセージの受信者を無効にします。それを破棄します）。

ApacheまたはカスタムHTTPヘッダーを介して、ブラウザーでそのような応答を識別してレンダリングしないようにする方法はありますか？

ヘッダーまたは本文の特別なコンテンツ特定の応答のは、攻撃者がそのコンテンツを単に省略、削除、または変更するため、明らかに機能しません。結局のところ、攻撃者がブラウザの受信内容を制御していると想定しているため、メッセージに「 evil bit 」を設定して、ブラウザがメッセージをレンダリングしないようにすることはできません。応答がブラウザに到達したため、そのようなマークはもうありません。ただし、man-in-the-middle攻撃のリスクを軽減するために使用できるセキュリティ関連のヘッダーがいくつかあります。

HSTS（HTTP Strict Transport Security、実際のヘッダーはStrict-Transport-Security）は大きなものです。これは、有効期間といくつかのオプションのフラグを指定します。通常、有効期間が長い（1年以上をお勧めします）すべての応答に設定するという考え方です。また、「 preload 」を使用して、ユーザーが初めてサイトにアクセスする前に保護することもできます。生涯にわたって、2つの主な効果があります：
- 別のWebページまたはユーザーがサイトのURLのhttp：//バージョンに明示的に移動しようとしても、サイトが安全でないHTTPを介してロードされることはありません。
- ユーザーは、そのサイトのHTTPSエラー（証明書が無効であるなど）を上書きすることはできません。つまり、ユーザーが愚かにもセキュリティエラーを無視し、man-in-the-middle攻撃を受けているときにページにアクセスしようとしても、ブラウザはそれを許可しません。
HTTP公開鍵ピンニング（HPKP）は、HSTSほどサポートされていませんが、一部のブラウザーはそれを尊重しています。 HPKPはHSTSのように機能します（HSTSと組み合わせて使用する必要があります）。ヘッダーには、ディレクティブの存続期間が含まれます。 HPKPには、証明書の公開鍵情報の拇印を指定する必須フィールドも含まれています。指定された有効期間（ブラウザーが信頼できる接続を介してそのヘッダーを確認するたびに更新される）の間、ブラウザーは、HTTPS証明書またはその発行された祖先の1つ（証明書に署名した認証局、またはその1つ）に対してそれを要求します。祖先）、ヘッダーの拇印は、証明書の公開鍵情報のハッシュと一致します。これにより、man-in-the-middle攻撃によってサイトが危険にさらされるのを防ぎます攻撃者がドメインに対して有効であるが不正に発行された証明書を取得できたとしてもこれは通常受け入れられ、信頼できると見なされます。基本的に、このサイトには「ブラウザさん、将来、他のキーを使用する証明書が表示された場合は、それを信用しないでください他の方法で有効であっても "と書かれています。すべてのCAが同等に信頼できるわけではなく、ドメインの証明書の発行を許可されるCAを制限する（他の）方法がないため、HSTSは、侵害されたCAや悪意のあるCAのまれな脅威に対してもある程度のセキュリティを提供できます。