Web安全一直是互联网用户非常关心的话题,无论是国际互联网组织还是浏览器厂商,都在尽力使用各种策略和限制来保障用户的信息安全。然而,这种好的出发点,却极可能被心怀不轨的人利用(即被“策反”),来对用户进行追踪,带来更多的隐私泄露问题和其他的安全隐患。
一、首先,介绍两个安全机制
(1)HTTP严格传输安全HSTS
HSTS(HTTP Strict Transport Security)[1],是国际互联网工程组织正在推行的Web安全协议,其作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接,用来抵御SSL剥离攻击。
图1 HSTS原理图
如图所示HSTS运作原理图,对其进行拆解:
1) 用户在浏览器中首次打开使用HSTS机制的网站时,如果使用HTTP协议①,则服务器会返回带有StaticTransport Security(STS)的HTTP头②,并通知浏览器将协议重定向为HTTPS,浏览器重新使用HTTPS协议与服务器进行连接③。
2) 用户浏览器客户端与服务器进行通信,服务器向浏览器发放证书④⑤。网站域名会被添加到浏览器的HSTS列表中,在之后与服务器的通信中强制使用HTTPS协议。当用户再次使用HTTP协议访问目标网站时⑥,会被HSTS机制强制转换为HTTPS协议进行连接建立和信息传输⑦。
HSTS Preload List:HSTS preload list是Chrome浏览器中的HSTS预载入列表,该列表中的域名被硬编码在了浏览器中,当访问列表中的网站时,即便是第一次访问,也会默认使用HTTPS协议,用户网站需要申请和审核才能加入列表。Firefox、Safari、Edge等浏览器均采用这个列表,下面讲述中所使用的列表中的域名当时均不在Preload List中。
(2)内容安全策略CSP
CSP(Content Security Policy)[2],是一个附加的安全层,可以通过 HTTP 头信息的Content-Security-Policy字段,或者网页的标签进行设置,用来帮助检测和缓解XSS、数据注入等攻击。
图2Github CSP配置信息
内容安全策略通过包含Content-Security-Policy的HTTP头来创建一个白名单制度,规定浏览器只允许加载和执行白名单域中的资源和代码。如果不在白名单域中,即便攻击者发现了漏洞,也无法实施注入攻击。图2为Github的CSP相关配置,配置相关细节见参考[3][4]。
(3)安全&危险
HTTP严格传输安全(HTST)和内容安全策略(CSP)这两个新的功能已经被内置到了Firefox和Chrome浏览器,并且之后很有可能也被其他主流浏览器支持。
一位研究学者将这两个安全机制结合进行利用,即使在用户删除浏览器历史记录的情况下,依然可以对用户浏览器访问过的域名进行获取,所获取的用户的访问历史列表可以用来追踪数百万的互联网用户。
是不是感觉本来用来保障用户安全的机制被“策反”了,成了对自己实施追踪的工具?下面我们将具体讲述,“策反”工作是如何执行的。
二、“策反”工作
Yan Zhu,一个独立的安全研究学者,在圣地亚哥的2015年Toorcon的安全会议上示范了自己开发的Sniffly追踪网站,Sniffly中内置了一个从Alexa网站上获取使用HSTS,并且不在HSTS Preload List中的域名,利用HSTS和CSP机制对用户浏览器访问过的域名进行嗅探。
如下图,访问http://zyan.scripts.mit.edu/sniffly/,页面中会显示用户已访问过和未曾访问过的域名列表。如图3为在Firefox上测试的结果,GitHub上已经有POC代码https://github.com/diracdeltas/sniffly/tree/master,目前Chrome48以上版本已经修复该漏洞。
图3Firefox对Sniffly测试的结果
Sniffly的工作原理(以bitcoin.org为例)
Sniffly使用形式设置CSP,而Firefox浏览器不支持这种方式,因此将对Chrome浏览器和Firefox浏览器上不同的工作原理分别进行讲述。
(一) Chrome浏览器
(1) 首次访问使用HSTS的情况
当用户第一次使用HTTP协议访问bitcoin.org时,服务器返回包含STS和CSP的HTTP头,通知浏览器使用HTTPS协议访问网站,并且只执行CSP规定域中的资源。图4展示了HTTP重定向到HTTPS的耗时情况。
图4HTTP连接重定向耗时
(2) 曾访问过HSTS目标网站的情况
当用户已经访问过使用HSTS的目标网站时,即bitcoin.org已经被添加到了浏览器的HSTS列表中。如图5和6显示了用户第二次访问使用HSTS的网站,以及HSTS强制浏览器内部重定向为HTTPS协议与服务器进行交互的情况。
图5第二次访问使用HSTS网站
图6浏览器强制使用HTTPS协议
(3) CSP阻断HTTPS的重定向(Chrome浏览器)
Sniffly利用CSP的白名单策略,对资源的加载进行限制。Sniffly作为第一方网站,通过对使用了HSTS的网站(这里称作“第三方网站”)构建img请求(即加载第三方的img资源),实施CSP的阻断,Sniffly在Chrome浏览器的工作原理,如下图所示。
图7CSP截获HTTPS重定向过程
如图7所示CSP截获HTTPS的重定向过程,对其进行拆解:
1)CSP部署:用户打开Sniffly网站,通过网页的设置CSP为“img-srchttp”jk,即限制浏览器只可以加载使用HTTP协议的img资源。针对使用了HSTS机制的域名,构建img请求lo,图中为的情景1和2标识用户是否访问过目标网站(img的src随机生成,是为了屏蔽浏览器缓存的影响),如图8所示。
图8 Sniffly的CSP部署和随机img src 地址
2)未访问过目标网站:若用户浏览器未访问过bitcoin.org,则首先会进行HTTPS重定向m,更换HTTPS协议再次发起请求n,HTTPS协议的img请求会被Sniffly的CSP阻断(如图9)。
3)曾访问过目标网站:若用户浏览器曾访问过bitcoin.org,由于使用了HSTS机制,HTTP请求在浏览器内被强制转换为HTTPS协议p,HTTPS协议的img请求会被Sniffly的CSP阻断,如图9所示。
图9 Sniffly对HTTP协议进行阻断
注:使用CSP阻断HTTPS不只为了获取重定向的时间,如果CSP未对HTTPS的重定向连接进行阻断,则成功连接后的HSTS机制会污染用户的访问历史,因此造成误判。
(二) Firefox浏览器
由于Firefox浏览器不支持通过的形式设置CSP,因此Sniffly利用了浏览器的漏洞Issue436451[8]对Firefox历史列表进行嗅探,该漏洞同样利用HSTS机制,如图10所示(图中隐去了PreloadList部分)。
图10 Issue436451漏洞原理示意图
利用该原理构造类似http://example.com:443/favicon.ico 的请求,浏览器对曾经访问过的目标网站使用HTTPS协议与服务器连接,而未访问过的域名,则无法正常建立连接,因此这种方式不会污染浏览器的HSTS列表,如图11所示使用fidder抓包的效果。
图11 Firefox中构造的img请求示意图
(三) 结果判定
由图4和图5可以得出,通过服务器301/302进行的HTTPS重定向耗时在100毫秒以上,而浏览器内部重定向(Internal Redirect)几乎不耗时。通过CSP对HTTPS进行阻断,利用JS中img的onerror事件进行监听,只获取重定向消耗的时间,通过计算时间的消耗对用户是否访问使用HSTS的网站进行判定。
不同用户的浏览记录千差万别,以浏览器历史信息作为用户的追踪依据,能够保证用户的唯一性,并且Sniffly中的列表只是使用Alexa网站中网站列表的很小一部分。
不同浏览器中的HSTS位置
Firefox的HSTS列表:打开Firefox的文件浏览,在地址栏中输入%APPDATA%\Mozilla\Firefox\Profiles\,双击其中的目录,在文件夹中找到SiteSecurityServiceState.txt,其中包含着HSTS的列表。
图12Firefox中的HSTS列表
Chrome的HSTS列表:在Chrome浏览器中,打开chrome://net-internals/#hsts,可以在其中查询、增加、删除本地HSTS相关的域名信息。
图13Chrome中的HSTS列表
(四) 第二代追踪Sniffly2
以上的技术实现均为第一代的Sniffly,Yan已经实现了第二代的Sniffly2。Sniffly2主要针对基于Chromium引擎的浏览器,使用HSTS的header和Performance Timing API嗅探浏览器的历史记录,同样是使用时间差机制对用户是否访问过目标网站进行判断。
三、最后
目前这种追踪方式,仅仅能够追踪到使用HSTS保护的网络站点,并且只对域名和子域名进行了记录。如果用户的浏览器装有HTTPS Everywhere[11]插件(强制所有支持HTTPS的站点使用安全连接),这种追踪方式也是没有效果的,不过,这个缺点在之后应该通过修改代码就能够解决。
四、参考资料:
* 本文作者:ArkTeam/Hey-x1,转载请注明来自FreeBuf.COM