无视HTTPS发起中间人攻击
大约十年前，Firesheep制造了一个大新闻。多年来，安全人员已经了解了公共WiFi网络的危害，但直到有人创建了这个用户友好的Firefox扩展插件之后，这个安全问题才得到了人们的关注。从那时起，网络上发生了很多事情，那么这样的事情还有可能再发生吗？
TL; DR; 由于HTTPS的存在，MITM攻击目前不再是一个问题。但是，使用CORS，postMessage和其他一些很酷的东西，有时也可以绕过HTTPS。虽然这是网站所有者的错，但受害的却是用户。
几年前Firesheep是人们脑海中最重要的东西。在那个年代的网站，比如说Facebook，默认情况下还没有开始使用HTTPS。移动设备（包括笔记本电脑和手机）的急剧增加使得连接到不受信任的WiFi网络变得越来越普遍。
八年后的今天，这实际上不再是一个问题。这是由于HTTPS的广泛采用，让大量的网络流量能够被加密传输。就在上周，WIRED发表了一篇名为“ 关于使用酒店的Wi-Fi 你知道些什么？。来自你的设备的流量现在已被加密，即使有人发起MITM攻击，你也不会受到什么太多的影响。这绝对是真的，当谈论到安全性时，你在酒店或咖啡店所提到的第一件事情就是MITM，但它已经发生了很大的变化。
当你在假期旅行时，从机场到上飞机再到入住酒店，你可能会发现自己面临着一个熟悉的困境：我真的要选择信任这些随机的公共Wi-Fi网络吗？就在几年前，答案几乎肯定是选择不信任。但是在2018年，你的回答可能会有不同。– Wired
然而，即使网络流量被加密了，但如果有人发起了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在你的威胁模型中，那么这些都是不应忽视的问题。
大约十年前，Firesheep制造了一个大新闻。多年来，安全人员已经了解了公共WiFi网络的危害，但直到有人创建了这个用户友好的Firefox扩展插件之后，这个安全问题才得到了人们的关注。从那时起，网络上发生了很多事情，那么这样的事情还有可能再发生吗？
TL; DR; 由于HTTPS的存在，MITM攻击目前不再是一个问题。但是，使用CORS，postMessage和其他一些很酷的东西，有时也可以绕过HTTPS。虽然这是网站所有者的错，但受害的却是用户。
几年前Firesheep是人们脑海中最重要的东西。在那个年代的网站，比如说Facebook，默认情况下还没有开始使用HTTPS。移动设备（包括笔记本电脑和手机）的急剧增加使得连接到不受信任的WiFi网络变得越来越普遍。
八年后的今天，这实际上不再是一个问题。这是由于HTTPS的广泛采用，让大量的网络流量能够被加密传输。就在上周，WIRED发表了一篇名为“ 关于使用酒店的Wi-Fi 你知道些什么？。来自你的设备的流量现在已被加密，即使有人发起MITM攻击，你也不会受到什么太多的影响。这绝对是真的，当谈论到安全性时，你在酒店或咖啡店所提到的第一件事情就是MITM，但它已经发生了很大的变化。
www.wnhack.com
当你在假期旅行时，从机场到上飞机再到入住酒店，你可能会发现自己面临着一个熟悉的困境：我真的要选择信任这些随机的公共Wi-Fi网络吗？就在几年前，答案几乎肯定是选择不信任。但是在2018年，你的回答可能会有不同。– Wired
然而，即使网络流量被加密了，但如果有人发起了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也会随之发送。
copyright 无奈人生
另一个非常常见的问题是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在你的威胁模型中，那么这些都是不应忽视的问题。