如何避免浏览器在发送响应后呈现恶意内容
How to avoid browser from rendering malacious content after the response is dispatched
我们目前正在研究 OWASP 安全修复程序，并且我们确定了一种攻击场景，我们正试图找出一种可能的解决方案：
- 用户向我们的应用程序发送了一个有效的 HTTPRequest。用户浏览器中的 URL 设置为我们的应用程序 url 例如http(s)://www.abc.com/request
- 应用程序通过 Apache 处理请求并分派响应。
- 虽然响应是 en-route，但攻击者会拦截响应并将整个响应的内容替换为某些恶意站点或消息，例如 'You Are Hacked!!'
- 响应在用户浏览器中呈现，URL 仍指向浏览器中的 http(s)://www.abc.com/request，但内容是恶意的。这让用户相信它仍然在我们的应用程序中。
我们可以通过我们的代理工具复制这个场景。有什么方法可以识别并防止通过 Apache 或自定义 HTTP headers 在浏览器中呈现此类响应？
任何 help/pointers 将不胜感激。
在第一个答案后添加：
再考虑一种情况：
- 用户向我们的应用程序发送了一个有效的 HTTPRequest。
- 攻击者拦截请求并将其转发到某个恶意站点而不是我们的应用程序。在这里，用户浏览器中的 URL 也设置为应用程序 URL 例如http(s)://www.abc.com/request 但内容将是恶意站点的内容。
这也可以通过 HTTPS 实现。
在场景 (2) 中，我们的网站是 HTTPS，而恶意网站是纯 HTTP。因此，当路由请求时，浏览器上不会出现证书警告。
对于 HTTP，您对此无能为力，因为拦截器还可以修改任何 HTTP headers，而不仅仅是内容。如果您的应用程序响应的真实性很重要，请完全不要通过 HTTP 提供服务，并教育您的用户使用和验证 HTTPS 网站。
使用 HTTPS，攻击者应该无法在用户浏览器没有注意到和中止的情况下替换响应的内容，因此第一种情况的第 3 步应该是不可能的。 'Should'，因为这假定 HTTPS 和底层加密的安全性，并且攻击者无法获得受攻击域的技术上有效的证书。
编辑：
在上述假设的限制下，您的第二种情况的第 2 步也应该不可能使用 HTTPS。 （HTTPS 被保存，安全实施并且攻击者没有持有被攻击域的证书。）如果您的代理 是 能够执行此攻击（或第一个场景中的那个）在 HTTPS 连接上，请
- 确保代理这样做时没有访问您服务的证书私钥
- 确保呈现给客户的 url 确实来自您服务的域
- 如果两者都是，请按照负责任的披露通知受影响软件的维护者（可能是客户端软件，如在第二种情况下，请求甚至可能无法到达真正的服务）
我们目前正在研究 OWASP 安全修复程序，并且我们确定了一种攻击场景，我们正试图找出一种可能的解决方案：
- 用户向我们的应用程序发送了一个有效的 HTTPRequest。用户浏览器中的 URL 设置为我们的应用程序 url 例如http(s)://www.abc.com/request
- 应用程序通过 Apache 处理请求并分派响应。
- 虽然响应是 en-route，但攻击者会拦截响应并将整个响应的内容替换为某些恶意站点或消息，例如 'You Are Hacked!!'
- 响应在用户浏览器中呈现，URL 仍指向浏览器中的 http(s)://www.abc.com/request，但内容是恶意的。这让用户相信它仍然在我们的应用程序中。
我们可以通过我们的代理工具复制这个场景。有什么方法可以识别并防止通过 Apache 或自定义 HTTP headers 在浏览器中呈现此类响应？
任何 help/pointers 将不胜感激。
在第一个答案后添加：
再考虑一种情况：
- 用户向我们的应用程序发送了一个有效的 HTTPRequest。
- 攻击者拦截请求并将其转发到某个恶意站点而不是我们的应用程序。在这里，用户浏览器中的 URL 也设置为应用程序 URL 例如http(s)://www.abc.com/request 但内容将是恶意站点的内容。
这也可以通过 HTTPS 实现。
在场景 (2) 中，我们的网站是 HTTPS，而恶意网站是纯 HTTP。因此，当路由请求时，浏览器上不会出现证书警告。
对于 HTTP，您对此无能为力，因为拦截器还可以修改任何 HTTP headers，而不仅仅是内容。如果您的应用程序响应的真实性很重要，请完全不要通过 HTTP 提供服务，并教育您的用户使用和验证 HTTPS 网站。
使用 HTTPS，攻击者应该无法在用户浏览器没有注意到和中止的情况下替换响应的内容，因此第一种情况的第 3 步应该是不可能的。 'Should'，因为这假定 HTTPS 和底层加密的安全性，并且攻击者无法获得受攻击域的技术上有效的证书。
编辑：
在上述假设的限制下，您的第二种情况的第 2 步也应该不可能使用 HTTPS。 （HTTPS 被保存，安全实施并且攻击者没有持有被攻击域的证书。）如果您的代理 是 能够执行此攻击（或第一个场景中的那个）在 HTTPS 连接上，请
- 确保代理这样做时没有访问您服务的证书私钥
- 确保呈现给客户的 url 确实来自您服务的域
- 如果两者都是，请按照负责任的披露通知受影响软件的维护者（可能是客户端软件，如在第二种情况下，请求甚至可能无法到达真正的服务）