无视HTTPS发起中间人攻击

 大约十年前，Firesheep制造了一个大新闻。多年来，安全人员已经了解了公共WiFi网络的危害，但直到有人创建了这个用户友好的Firefox扩展插件之后，这个安全问题才得到了人们的关注。从那时起，网络上发生了很多事情，那么这样的事情还有可能再发生吗?

TL; DR; 由于HTTPS的存在，MITM攻击目前不再是一个问题。但是，使用CORS，postMessage和其他一些很酷的东西，有时也可以绕过HTTPS。虽然这是网站所有者的错，但受害的却是用户。

几年前Firesheep是人们脑海中最重要的东西。在那个年代的网站，比如说Facebook，默认情况下还没有开始使用HTTPS。移动设备(包括笔记本电脑和手机)的急剧增加使得连接到不受信任的WiFi网络变得越来越普遍。

[[256498]]

八年后的今天，这实际上不再是一个问题。这是由于HTTPS的广泛采用，让大量的网络流量能够被加密传输。就在上周，WIRED发表了一篇名为“ 关于使用酒店的Wi-Fi 你知道些什么?。来自你的设备的流量现在已被加密，即使有人发起MITM攻击，你也不会受到什么太多的影响。这绝对是真的，当谈论到安全性时，你在酒店或咖啡店所提到的第一件事情就是MITM，但它已经发生了很大的变化。

当你在假期旅行时，从机场到上飞机再到入住酒店，你可能会发现自己面临着一个熟悉的困境：我真的要选择信任这些随机的公共Wi-Fi网络吗?就在几年前，答案几乎肯定是选择不信任。但是在2018年，你的回答可能会有不同。

然而，即使网络流量被加密了，但如果有人发起了MITM攻击，仍然会发生很多不好的事情。可以从几个角度出发讨论这个话题。本文将重点介绍如何利用现代Web技术继续发起MITM攻击，以及网站所有者该如何阻止这种攻击。

(WIRED发布的文章仍然有一个有效的观点，但也有很大技术讨论空间。)

攻击场景的其余部分将基于下面的一些条件

你正在酒店过夜，并将你的设备连接到酒店的WiFi。由于你处于不受信任的网络中，因此你可能不会去浏览任何敏感的信息。

但是，你正在使用与往常相同的浏览器会话。出于方便，人们永远不会退出Facebook或他们的工作电子邮件。

HSTS和cookie标志

我们需要从一些有关HSTS的基本信息开始。

HSTS是一个HTTP标头，它指示浏览器后续只应尝试通过HTTPS的方式加载该页面。从浏览器第一次访问具有此标头的网站时，它会将域名添加到列表中，并在标头中指定的时间内记住它。即使我明确的写了http://网页浏览器也会直接通过HTTPS发送请求。

也可以添加一个标志来预先加载标头。当Web浏览器获取更新或下载时，会包含预加载的域名列表。Web浏览器将拒绝向这些域名发送HTTP流量，即使用户第一次访问这些站点也是如此。

HSTS的另一个重要特性是名为includeSubDomains的标志。如果https://example.com包含此标头，则Web浏览器将拒绝发送任何未加密的流量到http://foo.example.com。

HSTS标头只能在HTTPS请求中设置。根据规范，这个标头在HTTP请求上应该是不起作用的(实际上没有经过足够多的浏览器测试来确定这一点)。当人们按以下顺序进行重定向时，这会导致一个常见问题：

http://example.com>

http://www.example.com>

https://www.example.com

由于第一个HTTPS请求将转到www. 因此includeSubDomains-flag并不起作用的，因为必须在apex域名上设置。

最后，还需要提到的一个东西是安全标志(secure)。这是在创建cookie时在cookie上设置的标志。设置此标志后，将永远不会通过HTTP发送cookie。如果向http://example.com发出请求则响应看起来像是用户没有保存的cookie一样。

CORS

我们之前在这里已经提到过一些关于CORS常见的错误配置。如果你还没有正确配置，那么我建议你先阅读那篇文章。

最简单的攻击方式是压根儿不使用HSTS。假设CORS已经启用，那么http://example.com可以请求https://example.com并读取数据。这在MITM场景中是可能发生的，因为发出请求的那个请求是通过HTTP托管的。由于实际的请求将通过HTTPS发送，因此即使带有secure标志的cookie也会随之发送。

另一个非常常见的问题是CORS允许访问任何子域名，但HSTS没有设置includeSubDomains-标志。这意味着攻击者能够在http://foobar.example.com上托管恶意的javascript然后向https://example.com发出请求。在MITM攻击场景中，攻击者可以随意构造他们想攻击的任何子域名。在讨论HSTS时，我们在前面已经解释过，它存在一个重定向问题，因此当主应用程序托管在www上时，这种攻击手法就很常见的。

一个有趣的攻击向量是在使用HSTS时，CORS可以支持多个域名。我们用一个真实的案例来说明一下，在periscope.tv上的CORS可以通过HTTP和HTTPS接受*.periscope.tv，*.pscp.tv和*.twitter.com。只要有人登录到periscope.tv，HSTS就会确保后续的请求不会通过HTTP发送到该域名。但是，受害者之前从未访问过*.pscp.tv的可能性很大，而且在MITM攻击场景中，攻击者可以在那里伪造一个HTTP的页面并发送请求到periscope.tv。在这种情况下，这种攻击将被阻止，因为所有这些域名的所有HSTS策略都是预加载的。

postMessage

正如我们之前所述，在使用postMessage时检查消息的来源非常重要。但是，这些检查仅检查来源是否以特定内容作为结尾并因此导致攻击者可以匹配任何子域名，这是个很常见的问题。这意味着完全没有检查协议。任何子域名上的HTTP页面都能够将消息发送到主应用程序。

还有一些基于正则表达式的来源检查，有意允许了HTTP和HTTPS，即使Web应用程序应该只能通过HTTPS使用也会允许匹配HTTP。还应该注意的是，有几种网络协议实际上也可以托管Web内容，例如FTP。因此，务必确保将HTTPS列入了白名单，而不是将HTTP列入黑名单。相关案例请查看：https://hackerone.com/reports/210654

至于与HSTS的组合使用，实际上与CORS的问题遵循的是相同的原则。

WebSocket

WebSocket实际上在握手请求中共享了cookie，因此需要用与CORS请求相似的方式进行源的检查。这仅在应用程序需要关注cookie数据时才很重要，因此并不总是适用于很多情况。

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

可能已经有一些类似的方式或技术以上述类似的方式被滥用。如果今天没有，那很快就会有。如果MITM在你的威胁模型中，那么这些都是不应忽视的问题。

修复建议

网站所有者

HSTS

第一步是在网站上开始使用HSTS，因为今天许多人都没有这样做。在已经通过HTTPS提供服务的网站上，这样做没有任何问题。当你实现了HSTS并确保它正常工作时，记得添加关于预加载它的标志。

如果可能，请在HTTP头中包含includeSubDomains-header。但是，这将要求所有子域名也要通过HTTPS提供所有流量，不过这取决于具体情况并且可能有点困难。

CORS

确保CORS仅接受HTTPS请求。因为最常见的解决方案是反射源，即使源与模式匹配成功，也需要检查它是否https://开头。

postMessage和WebSocket

与CORS非常相似：确保检查了源并检查了协议而不仅仅是主机名。

普通用户

在写这篇文章之前，我曾与几个有这些安全问题的大网站的安全人员联系过。虽然许多人都比较关心这个问题，但也有几个人认为这是可以接受的风险。他们认为受害者不太可能受到这样的MITM攻击或类似的理由。因此，尽管应该由网站所有者负责修复，但用户也必须关心这个问题。

· 第一步是安装HTTPS Everywhere。它是一个浏览器插件，类似于HSTS，但是在客户端上。

· 第二个建议是不要使用公共WiFi。自Firesheep时代以来的最大变化也是移动数据的价值的变化。许多经常连接到开放网络的人也会用手机连接这些开放式网络。

· 如果上面一条不适用于你，那第二个最好的建议是使用科学。但是，应该明白的是，这也不是一种防御策略。由于许多公共热点在你连接时都有某种登录页面，因此你实际上必须连接到网络一段时间，而不会有流量通过科学。在此期间，热点会强制你的设备发出前文所描述的技术的网络请求。

…

让我再次引用WIRED文章作为本文所有内容的结束。请记住，要对自己的情况进行风险分析，然后采取行动。