通过仅通过 HTTPS 提供站点来缓解 SSLStrip?

信息安全 tls 中间人 ssls带
2021-09-07 17:09:45

所以我现在才了解 SSLStrip——我觉得我玩游戏太晚了。我想知道的是:如果您的网站仅通过 HTTPS 提供内容并且在 HTTP 请求上出现硬故障,没有重定向,您是否仍然容易受到攻击?如果您在浏览器的地址栏中键入内容,攻击者能否拦截您的 HTTPS 请求并“代表您”执行请求,可以这么说,并为您的浏览器提供 HTTP 版本?(使用 SSLStrip 或其他攻击?)


TL:DR;

下面 user10008 给出了答案。SSLStrip 不依赖于服务器的行为,它依赖于客户端。如果您可以让客户端通过 HTTP 而不是 HTTPS 发出请求,那么即使服务器仅支持 HTTPS,您也可以执行攻击。HSTS 阻止浏览器首先执行纯 HTTP 请求(在后续请求中)。

4个回答

是的,如果不采取进一步措施,攻击者仍然可以执行 SSLStrip。要使 SSLStrip 起作用,攻击者只需成为中间人,与您对 HTTP 的行为无关。在传入的 HTTP 请求中,攻击者将打开与真实服务器的 HTTPS 连接,并从 HTTPS 中“剥离”SSL。因此,攻击者和服务器之间将没有 HTTP 通信。即使服务器的 HTTP 行为看起来无关紧要,最好还是禁用 HTTP 或创建永久重定向来进一步缓解。

当您只提供 HTTPS 并且您确定将来需要 HTTPS 时,您可以通过使用HTTP 严格传输安全 (HSTS)告诉用户您只提供 HTTPS来部分缓解。这将在所有用户至少连接一次而不受攻击的情况下缓解 SSLStrip。

您可以通过请求将自己添加到 HSTS白名单来实现 Firefox 和 Chrome 的完全缓解Firefox 和 Chrome 假定该白名单上的网站使用 HTTPS,但要在该列表中,要求发送 HSTS 标头。在此处申请的更多信息

如果您的网站仅通过 HTTPS 提供内容,并且在 HTTP 请求上出现硬故障,没有重定向,您是否仍然容易受到攻击?

如果用户不小心输入http://example.com了地址栏而不是https://example.com, sslstrip 仍然可以拦截连接并欺骗用户。

用户跟踪恶意链接的情况也可能如此——如果他们没有注意到地址栏中丢失的挂锁,他们可能很容易受到攻击。

如果您发送标头, HTTP Strict Transport Security可以防止这种情况发生,但前提是用户之前使用该特定实例通过 HTTPS 访问过您的站点(如果他们的浏览器),或者您已要求浏览器供应商将您的站点包含在预加载的 HSTS 中列表。请注意,IE 还不支持 HSTS

另一件需要注意的事情是,除非您将cookie 标记为安全,否则攻击者可能能够 MITM 来自受害者的任何其他 HTTP 请求,并向您网站的不安全版本注入请求(例如,添加<img src="http://example.com/mitm.jpg" />这将允许他们对任何 cookie 进行 MITM为您的网站。请注意,HSTS 也将防止这种情况。

此外,如果您的站点上存在任何通过呈现 cookie 值的 XSS 漏洞,则攻击者可能会使用 MITM 攻击在此处注入恶意脚本,除非 HSTS 处于活动状态。即使您正在设置安全 cookie,这也是可能的 - 服务器在读取它们时无法区分哪些 cookie 是安全的(它只获取值),因此它不知道攻击者在 MITM 攻击期间是否通过任何 HTTP 连接操纵了任何东西你的服务器。

我已经在上面介绍了相当多的内容,扩展了您所询问的内容,但是这些都是可以使用的所有类型的攻击,即使您没有在服务器端通过纯 HTTP 进行侦听。

攻击者能否拦截您的 HTTPS 请求并“代表您”执行请求,可以这么说,并为您的浏览器提供 HTTP 版本

如果您直接访问 HTTPS 站点(例如从书签),那么 SSLStrip MITM 攻击的可能性很小。由于浏览器正在寻找 TLS 握手,请求会失败,或者如果攻击者使用的是假证书,则会提示您证书错误。

现在,如果您在服务器端执行此操作,则不能总是依赖服务器将 HTTP 重定向到 HTTPS,因为此重定向可能会被拦截。

此外,如果您通过来自未加密来源的超链接访问该页面,您也将容易受到 SSLStrip 的攻击。我知道您的问题并没有具体询问最后两种情况,但我只是想提一下它们是彻底的。有一些方法可以通过使用 HSTS 来减轻后一种攻击。

使用HSTS,服务器会告诉 Web 客户端仅使用 HTTPS。只要对站点的第一次请求没有修改就完成了,所有后续对该站点的访问都将被强制使用 SSL/TLS。这将有助于防止 SSLStrip 处理来自不安全网站的超链接,即使https://已更改为仅http://知道使用的浏览器https://

由于攻击的一部分是对所有受害者 TCP/UDP 流量进行 MITM,只要用户不明确使用 https 地址,他就可能被欺骗。

例如:如果受害者尝试访问“mail.google.com”并信任 Google 所做的从 http 到 https 的自动重定向(自己尝试),但他没有检查地址栏得到钥匙锁图标/绿色酒吧/无论如何,已经完成 MITM 的攻击者将以明文形式从该站点获取所有流量。

尽管如此,有一个新的 HTTP 标头可以包含在所有服务器响应中,旨在最大限度地减少遭受此类攻击的机会,如果客户端之前至少成功连接过一次 HTTPS(并使用现代网络支持它的浏览器):

严格的运输安全

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

让 apache 服务器在所有响应中包含此标头:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

注意:如果您的网站同时拥有HTTP 和 HTTPS 版本,一旦客户端从您的服务器获取该标头,他将无法连接到 HTTP 版本(直到他删除 cookie 或使用不同的浏览器或(也许)使用私人导航)