利用HSTS嗅探浏览器历史纪录的三个漏洞

HSTS是让浏览器强制使用HTTPS访问网站的一项安全策略。HSTS的设计初衷是缓解中间人攻击带来的风险。本文主要介绍HSTS及其他Web功能带来的一些隐私问题，比如如何利用它们来探测浏览器的用户历史纪录。

作者 | tocttou

一、背景：什么是HSTS

HSTS的英文全称是HTTP Strict Transport Security，中文译作HTTP严格传输安全。2012年11月IETF发布RFC 6797，在这篇文档中正式定义了HSTS。HSTS的开启方式是在HTTP响应头中加入Strict-Transport-Security字段。如：Strict-Transport-Security: max-age=31536000 。

这意味着在接下来的31536000秒内（1年），当浏览器需要访问同一个域名时，必须使用HTTPS，并且用户不可以忽略证书错误警告。使用HSTS避免了一系列的中间人攻击问题，比如HTTPS剥离攻击 [1]、HTTPS Cookie注入攻击 [2]等。

设置HTTP响应头的方法虽然可以规避大量的中间人攻击，但是用户的第一次访问仍然是不受HSTS保护的。于是诞生了浏览器预置HSTS列表。网站站长可以主动向Chrome团队提交自己的域名。批准后，各主流浏览器厂商（不只是Chrome）会在编译新版浏览器时将你的域名硬编码进内置HSTS列表中。

现在已经有越来越多的网站开启了HSTS，比如Google、百度、支付宝等。根据trustworthyinternet.org 发布的SSL Pulse报告显示，截至2017年5月，有11.8%的网站支持HSTS [3]。最新版的主流浏览器也都支持HSTS，比如Chrome、Edge、IE 11、Firefox、Opera、Safari等。

二、漏洞一：利用端口号和<img>标签探测历史纪录

上一节所述的都是HSTS好的一方面，下面来说HSTS导致的问题。第一个漏洞是我和Vlad Tsyrklevich在2014年独立发现的 [4][5]。简单来说，如果www.example.com开启了HSTS，如果用户没有访问过它，那么 http://www.example.com:443/favicon.ico 一定会访问失败。如果访问过，那么HSTS会使浏览器请求https://www.example.com:443/favicon.ico，这样就会成功（如果不存在favicon.ico这个图片的话，就任选一个这个域名下其他图片地址）。所以我们用<img src="http://www.example.com:443/favicon.ico" onerror="not_visited()" onload="visited()">，如果onerror被调用就说明没有访问过www.example.com，如果onload被调用就说明访问过。

这个方法有一定的限制，比如被测试的域名必须要使用HSTS，并且不能在HSTS预置列表中。而且只能判断一个域名是否访问过，而无法测试整个URL是否被访问过。

这个漏洞我报给了Chromium团队，报告和完整PoC可参见 [4]。我的建议是禁止http协议使用443端口。但是由于这样会给WebSocket造成兼容性问题，并且这个漏洞影响小，所以他们最终决定不修复这个漏洞。

网站可以把自己的域名提交到HSTS预置列表来规避这个漏洞。用户可以通过清空历史纪录避免这个漏洞，因为清空历史记录会同时清空动态设定的HSTS记录。

三、漏洞二：Sniffly — 利用HSTS和CSP探测历史纪录

这个漏洞是由雅虎的安全工程师Yan Zhu于2015年发现的。她在Toorcon 2015会议上讲述了这个漏洞（演讲视频参见[6]，幻灯片参见[7]），并把这个漏洞命名为Sniffly。Freebuf之前也有一篇文章《Sniffly： 利用HSTS和CSP嗅探浏览器历史记录》[8]，就是写这个漏洞的。

这个漏洞利用CSP（内容安全策略）来阻止https协议的图片，而同时允许http协议。这个CSP是这样设置的：Content-Security-Policy: img-src http://*。这样如果有一个http到https的重定向，那么这个CSP将在这个重定向发生之后，阻止https请求，并调用onerror handler。

攻击者可以使用JavaScript来测从http请求发出到https被阻止之间的时间间隔，这个时间间隔就是重定向所需时间。如果这个时间很短（小于10毫秒），那么我们可以认为浏览器没有向服务器发送任何请求，也就是说这个重定向来源于HSTS或者是缓存的301重定向。这样我们就知道用户曾经访问过这个域名。

这个漏洞很快地在Chrome中修复了，漏洞编号是CVE-2016-1617。修复方法是：如果CSP中指定了http://*，则它同时允许http和https协议。这样就没法用这个方法屏蔽http到https的重定向。Yan Zhu给Chrome提交的漏洞报告和PoC可参见 [9]。

四、漏洞三：利用HSTS、CSP和端口号探测历史记录

这个漏洞是我在2016年，看完漏洞二的细节后想出来的绕过方法。首先我们看Google对漏洞二的修复代码 [10]：

补丁在WebKit/Source/core/frame/csp/CSPSource.cpp文件中的CSPSource::schemeMatches函数中加入了下面4行代码：

这个代码的意思就是当CSP中的协议是http时，url的协议是http或https都能成功匹配。ws是WebSocket协议，同样CSP中指定的ws协议可以同时匹配ws和wss。

很显然这个修复只考虑了URL中的协议部分，所以我想到利用漏洞一中的技巧，我们在CSP中显式指定端口号，就绕过了修复。

比如，我们设置这个CSP策略：img-src http://example.com:80。漏洞二修复之后，这个CSP会允许http://example.com:80和https://example.com:80，但是后一个URL并没有意义，因为https不用80端口，而真正的https://example.com依然被阻止，因为https的端口号不匹配”:80”。有了这个思路之后，剩下的利用方法就和漏洞二一样了，也是测http到https的重定向时间。

这个漏洞同时存在于Chrome、Firefox、WebKit。但Edge、IE不存在这个漏洞。Edge是在https请求返回之后才调用onerror，所以Edge中无法计算重定向时间。

给Chrome的报告和PoC在[11]，给Mozilla的报告在[12]，给WebKit的报告在[13]。他们都早已修复完毕。漏洞编号是CVE-2016-5137（Chrome）和CVE-2016-9017（Firefox）。Google还给了我1000美元奖金。

五、总结

这篇文章主要介绍了什么是HSTS以及和HSTS相关的三个漏洞。这三个漏洞影响都不大，但是我写出来主要为了分享，如何灵活运用端口号这个技巧来绕过相关限制。HSTS其实还能当Cookie用，也是HSTS带来的隐私问题，鉴于和本文关系不大，就不涉及了，想了解的话可参见[14]。

六、参考文献

[1]https://blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

[2]https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-zheng-updated.pdf

[3]https://www.trustworthyinternet.org/ssl-pulse/

[4]https://bugs.chromium.org/p/chromium/issues/detail?id=436451

[5]https://bugzilla.mozilla.org/show_bug.cgi?id=1090433

[6]https://www.youtube.com/watch?v=kk2GkZv6Wjs

[7]https://zyan.scripts.mit.edu/presentations/toorcon2015.pdf

[8]http://www.freebuf.com/articles/87641.html

[9]https://bugs.chromium.org/p/chromium/issues/detail?id=544765

[10]https://chromium.googlesource.com/chromium/src.git/+/ab830edb26a1f56f660b06459d70e1d48a707975

[11]https://bugs.chromium.org/p/chromium/issues/detail?id=625945

[12]https://bugzilla.mozilla.org/show_bug.cgi?id=1285003

[13]https://bugs.webkit.org/show_bug.cgi?id=159520 （尚未公开）

[14]https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/