一、首先，介紹兩個(gè)安全機(jī)制
(1)HTTP嚴(yán)格傳輸安全HSTS
HSTS(HTTP Strict Transport Security)[1]，是國(guó)際互聯(lián)網(wǎng)工程組織正在推行的Web安全協(xié)議，其作用是強(qiáng)制客戶端(如瀏覽器)使用HTTPS與服務(wù)器創(chuàng)建連接，用來(lái)抵御SSL剝離攻擊。
圖1 HSTS原理圖
如圖所示HSTS運(yùn)作原理圖，對(duì)其進(jìn)行拆解：
1) 用戶在瀏覽器中首次打開(kāi)使用HSTS機(jī)制的網(wǎng)站時(shí)，如果使用HTTP協(xié)議①，則服務(wù)器會(huì)返回帶有StaticTransport Security(STS)的HTTP頭②，并通知瀏覽器將協(xié)議重定向?yàn)镠TTPS，瀏覽器重新使用HTTPS協(xié)議與服務(wù)器進(jìn)行連接③。
2) 用戶瀏覽器客戶端與服務(wù)器進(jìn)行通信，服務(wù)器向?yàn)g覽器發(fā)放證書(shū)④⑤。網(wǎng)站域名會(huì)被添加到瀏覽器的HSTS列表中，在之后與服務(wù)器的通信中強(qiáng)制使用HTTPS協(xié)議。當(dāng)用戶再次使用HTTP協(xié)議訪問(wèn)目標(biāo)網(wǎng)站時(shí)⑥，會(huì)被HSTS機(jī)制強(qiáng)制轉(zhuǎn)換為HTTPS協(xié)議進(jìn)行連接建立和信息傳輸⑦。
HSTS Preload List：HSTS preload list是Chrome瀏覽器中的HSTS預(yù)載入列表，該列表中的域名被硬編碼在了瀏覽器中，當(dāng)訪問(wèn)列表中的網(wǎng)站時(shí)，即便是第一次訪問(wèn)，也會(huì)默認(rèn)使用HTTPS協(xié)議，用戶網(wǎng)站需要申請(qǐng)和審核才能加入列表。Firefox、Safari、Edge等瀏覽器均采用這個(gè)列表，下面講述中所使用的列表中的域名當(dāng)時(shí)均不在Preload List中。
(2)內(nèi)容安全策略CSP
CSP(Content Security Policy)[2]，是一個(gè)附加的安全層，可以通過(guò) HTTP 頭信息的Content-Security-Policy字段，或者網(wǎng)頁(yè)的標(biāo)簽進(jìn)行設(shè)置，用來(lái)幫助檢測(cè)和緩解XSS、數(shù)據(jù)注入等攻擊。
圖2Github CSP配置信息
內(nèi)容安全策略通過(guò)包含Content-Security-Policy的HTTP頭來(lái)創(chuàng)建一個(gè)白名單制度，規(guī)定瀏覽器只允許加載和執(zhí)行白名單域中的資源和代碼。如果不在白名單域中，即便攻擊者發(fā)現(xiàn)了漏洞，也無(wú)法實(shí)施注入攻擊。圖2為Github的CSP相關(guān)配置，配置相關(guān)細(xì)節(jié)見(jiàn)參考[3][4]。
(3)安全&危險(xiǎn)
HTTP嚴(yán)格傳輸安全(HTST)和內(nèi)容安全策略(CSP)這兩個(gè)新的功能已經(jīng)被內(nèi)置到了Firefox和Chrome瀏覽器，并且之后很有可能也被其他主流瀏覽器支持。
一位研究學(xué)者將這兩個(gè)安全機(jī)制結(jié)合進(jìn)行利用，即使在用戶刪除瀏覽器歷史記錄的情況下，依然可以對(duì)用戶瀏覽器訪問(wèn)過(guò)的域名進(jìn)行獲取，所獲取的用戶的訪問(wèn)歷史列表可以用來(lái)追蹤數(shù)百萬(wàn)的互聯(lián)網(wǎng)用戶。
是不是感覺(jué)本來(lái)用來(lái)保障用戶安全的機(jī)制被“策反”了，成了對(duì)自己實(shí)施追蹤的工具?下面我們將具體講述，“策反”工作是如何執(zhí)行的。
二、“策反”工作
Yan Zhu，一個(gè)獨(dú)立的安全研究學(xué)者，在圣地亞哥的2015年Toorcon的安全會(huì)議上示范了自己開(kāi)發(fā)的Sniffly追蹤網(wǎng)站，Sniffly中內(nèi)置了一個(gè)從Alexa網(wǎng)站上獲取使用HSTS，并且不在HSTS Preload List中的域名，利用HSTS和CSP機(jī)制對(duì)用戶瀏覽器訪問(wèn)過(guò)的域名進(jìn)行嗅探。
如下圖，訪問(wèn)http://zyan.scripts.mit.edu/sniffly/，頁(yè)面中會(huì)顯示用戶已訪問(wèn)過(guò)和未曾訪問(wèn)過(guò)的域名列表。如圖3為在Firefox上測(cè)試的結(jié)果，GitHub上已經(jīng)有POC代碼https://github.com/diracdeltas/sniffly/tree/master，目前Chrome48以上版本已經(jīng)修復(fù)該漏洞。
圖3Firefox對(duì)Sniffly測(cè)試的結(jié)果
Sniffly的工作原理(以bitcoin.org為例)
Sniffly使用形式設(shè)置CSP，而Firefox瀏覽器不支持這種方式，因此將對(duì)Chrome瀏覽器和Firefox瀏覽器上不同的工作原理分別進(jìn)行講述。
(一) Chrome瀏覽器
(1) 首次訪問(wèn)使用HSTS的情況
當(dāng)用戶第一次使用HTTP協(xié)議訪問(wèn)bitcoin.org時(shí)，服務(wù)器返回包含STS和CSP的HTTP頭，通知瀏覽器使用HTTPS協(xié)議訪問(wèn)網(wǎng)站，并且只執(zhí)行CSP規(guī)定域中的資源。圖4展示了HTTP重定向到HTTPS的耗時(shí)情況。
圖4HTTP連接重定向耗時(shí)
(2) 曾訪問(wèn)過(guò)HSTS目標(biāo)網(wǎng)站的情況
當(dāng)用戶已經(jīng)訪問(wèn)過(guò)使用HSTS的目標(biāo)網(wǎng)站時(shí)，即bitcoin.org已經(jīng)被添加到了瀏覽器的HSTS列表中。如圖5和6顯示了用戶第二次訪問(wèn)使用HSTS的網(wǎng)站，以及HSTS強(qiáng)制瀏覽器內(nèi)部重定向?yàn)镠TTPS協(xié)議與服務(wù)器進(jìn)行交互的情況。
圖5第二次訪問(wèn)使用HSTS網(wǎng)站
圖6瀏覽器強(qiáng)制使用HTTPS協(xié)議
(3) CSP阻斷HTTPS的重定向(Chrome瀏覽器)
Sniffly利用CSP的白名單策略，對(duì)資源的加載進(jìn)行限制。Sniffly作為第一方網(wǎng)站，通過(guò)對(duì)使用了HSTS的網(wǎng)站(這里稱作“第三方網(wǎng)站”)構(gòu)建img請(qǐng)求(即加載第三方的img資源)，實(shí)施CSP的阻斷，Sniffly在Chrome瀏覽器的工作原理，如下圖所示。
圖7CSP截獲HTTPS重定向過(guò)程
如圖7所示CSP截獲HTTPS的重定向過(guò)程，對(duì)其進(jìn)行拆解：
1)CSP部署：用戶打開(kāi)Sniffly網(wǎng)站，通過(guò)網(wǎng)頁(yè)的設(shè)置CSP為“img-srchttp”jk，即限制瀏覽器只可以加載使用HTTP協(xié)議的img資源。針對(duì)使用了HSTS機(jī)制的域名，構(gòu)建img請(qǐng)求lo，圖中為的情景1和2標(biāo)識(shí)用戶是否訪問(wèn)過(guò)目標(biāo)網(wǎng)站(img的src隨機(jī)生成，是為了屏蔽瀏覽器緩存的影響)，如圖8所示。
圖8 Sniffly的CSP部署和隨機(jī)img src 地址
2)未訪問(wèn)過(guò)目標(biāo)網(wǎng)站：若用戶瀏覽器未訪問(wèn)過(guò)bitcoin.org，則首先會(huì)進(jìn)行HTTPS重定向m，更換HTTPS協(xié)議再次發(fā)起請(qǐng)求n，HTTPS協(xié)議的img請(qǐng)求會(huì)被Sniffly的CSP阻斷(如圖9)。
3)曾訪問(wèn)過(guò)目標(biāo)網(wǎng)站：若用戶瀏覽器曾訪問(wèn)過(guò)bitcoin.org，由于使用了HSTS機(jī)制，HTTP請(qǐng)求在瀏覽器內(nèi)被強(qiáng)制轉(zhuǎn)換為HTTPS協(xié)議p，HTTPS協(xié)議的img請(qǐng)求會(huì)被Sniffly的CSP阻斷，如圖9所示。
圖9 Sniffly對(duì)HTTP協(xié)議進(jìn)行阻斷
注：使用CSP阻斷HTTPS不只為了獲取重定向的時(shí)間，如果CSP未對(duì)HTTPS的重定向連接進(jìn)行阻斷，則成功連接后的HSTS機(jī)制會(huì)污染用戶的訪問(wèn)歷史，因此造成誤判。
(二) Firefox瀏覽器
由于Firefox瀏覽器不支持通過(guò)的形式設(shè)置CSP，因此Sniffly利用了瀏覽器的漏洞Issue436451[8]對(duì)Firefox歷史列表進(jìn)行嗅探，該漏洞同樣利用HSTS機(jī)制，如圖10所示(圖中隱去了PreloadList部分)。
圖10 Issue436451漏洞原理示意圖
利用該原理構(gòu)造類似http://example.com:443/favicon.ico 的請(qǐng)求，瀏覽器對(duì)曾經(jīng)訪問(wèn)過(guò)的目標(biāo)網(wǎng)站使用HTTPS協(xié)議與服務(wù)器連接，而未訪問(wèn)過(guò)的域名，則無(wú)法正常建立連接，因此這種方式不會(huì)污染瀏覽器的HSTS列表，如圖11所示使用fidder抓包的效果。
圖11 Firefox中構(gòu)造的img請(qǐng)求示意圖
(三) 結(jié)果判定
由圖4和圖5可以得出，通過(guò)服務(wù)器301/302進(jìn)行的HTTPS重定向耗時(shí)在100毫秒以上，而瀏覽器內(nèi)部重定向(Internal Redirect)幾乎不耗時(shí)。通過(guò)CSP對(duì)HTTPS進(jìn)行阻斷，利用JS中img的onerror事件進(jìn)行監(jiān)聽(tīng)，只獲取重定向消耗的時(shí)間，通過(guò)計(jì)算時(shí)間的消耗對(duì)用戶是否訪問(wèn)使用HSTS的網(wǎng)站進(jìn)行判定。
不同用戶的瀏覽記錄千差萬(wàn)別，以瀏覽器歷史信息作為用戶的追蹤依據(jù)，能夠保證用戶的唯一性，并且Sniffly中的列表只是使用Alexa網(wǎng)站中網(wǎng)站列表的很小一部分。
不同瀏覽器中的HSTS位置
Firefox的HSTS列表：打開(kāi)Firefox的文件瀏覽，在地址欄中輸入%APPDATA%\Mozilla\Firefox\Profiles\，雙擊其中的目錄，在文件夾中找到SiteSecurityServiceState.txt，其中包含著HSTS的列表。
圖12Firefox中的HSTS列表
Chrome的HSTS列表：在Chrome瀏覽器中，打開(kāi)chrome://net-internals/#hsts，可以在其中查詢、增加、刪除本地HSTS相關(guān)的域名信息。
圖13Chrome中的HSTS列表
(四) 第二代追蹤Sniffly2
以上的技術(shù)實(shí)現(xiàn)均為第一代的Sniffly，Yan已經(jīng)實(shí)現(xiàn)了第二代的Sniffly2。Sniffly2主要針對(duì)基于Chromium引擎的瀏覽器，使用HSTS的header和Performance Timing API嗅探瀏覽器的歷史記錄，同樣是使用時(shí)間差機(jī)制對(duì)用戶是否訪問(wèn)過(guò)目標(biāo)網(wǎng)站進(jìn)行判斷。
Github代碼：https://github.com/diracdeltas/sniffly
測(cè)試網(wǎng)站：http://diracdeltas.github.io/sniffly/
三、最后
目前這種追蹤方式，僅僅能夠追蹤到使用HSTS保護(hù)的網(wǎng)絡(luò)站點(diǎn)，并且只對(duì)域名和子域名進(jìn)行了記錄。如果用戶的瀏覽器裝有HTTPS Everywhere[11]插件(強(qiáng)制所有支持HTTPS的站點(diǎn)使用安全連接)，這種追蹤方式也是沒(méi)有效果的，不過(guò)，這個(gè)缺點(diǎn)在之后應(yīng)該通過(guò)修改代碼就能夠解決。
| 
