側信道嗅探瀏覽器歷史
TL;DR
本文發表在 WOOT'18: Proceedings of the 12th USENIX Conference on Offensive Technologies
在本文中，作者介紹了通過一些側信道形式嗅探用戶是否訪問過某網站的方法，盡管發的會不是很出名，但是個人認為整個思路還是很有意思的，也學到了一些東西，所以寫了一下比較長篇的筆記介紹。因為自己不經常寫筆記，所以寫的有點像翻譯文章，今后如果時間精力允許會更簡潔一些。（但是確實我覺得文章思路很棒的說
Introduction
作者在本篇中提出了四個新的嗅探用戶訪問歷史 ( history sniffing ) 的攻擊，主要分兩類：針對訪問過的鏈接的攻擊形式 ( visited-link attack ) 和基于緩存的攻擊 ( cache-based attack ) 。這些攻擊通過濫用新的瀏覽器功能（例如， CSS 繪畫 API 和 JavaScript 字節碼緩存等）來實現，主要利用的是瀏覽器在處理跨源 URL 數據時忽略了隱私問題。作者評估了針對以下瀏覽器的攻擊，四個主要的瀏覽器（Chrome、Firefox、Edge 和 IE ）以及 幾個注重安全的瀏覽器（ChromeZero, Brave, FuzzyFox, DeterFox, 和Tor瀏覽器）。作者的兩個攻擊對除 Tor 瀏覽器以外的所有瀏覽器都是有效的，而另外兩個攻擊則針對 Chrome 瀏覽器的特定功能，而另外兩個攻擊則針對 Chromium 衍生的瀏覽器。此外，作者的一個針對訪問鏈接的攻擊（CVE- 2018-6137）可以以每秒 6,000 個 URL 的速度竊取用戶的歷史記錄。作者希望這項工作將推進瀏覽器供應商進一步重新考慮處理隱私敏感數據的瀏覽器功能設計。
在現代社會中，通過一個人的瀏覽器歷史記錄可以分析出這個人的一些特征，比如年齡、性別、地點等，所以瀏覽器歷史記錄作為個人隱私也顯得極為重要；雖然瀏覽器沒有為 JavaScript 提供直接的手段來讀出用戶的歷史，但是在實際中，瀏覽器仍然允許網頁開發者對歷史數據進行有限的操作，例如使用 CSS 當中的 :visited 和 :link 選擇器，開發者可以根據一個鏈接的目標 URL 是否出現在用戶的瀏覽歷史中而有條件地設計它，而攻擊者更可以通過類似的方式獲取到歷史記錄。所以瀏覽器必須考慮到各種濫用，比如利用 CSS 選擇器作為側面渠道，"嗅探 "一個URL的訪問狀態。
早在2002年，攻擊者就發現了可以通過檢測 :visited 選擇器是否與給定的鏈接元素相匹配的方法，通過將鏈接的目的地指向感興趣的URL，他們可以泄露受害者是否訪問過該 URL ；攻擊者發現他們可以濫用不同的瀏覽器功能，如 MozAfterPaint 事件或 requestAnimationFrameAPI，來竊取相同的數據，或者可以使用 :visited 選擇器來欺騙他們的受害者，讓他們泄露信息；攻擊者還可以通過基于瀏覽器對嵌入式資源（如圖像或腳本）的緩存的時機渠道來泄露歷史信息。雖然瀏覽器在發現漏洞時很及時地修補了漏洞，但是他們急于支持新的功能和新的 API ，以適應新的應用類別，從視頻游戲到物聯網到虛擬和增強現實。當然，為了確保新的應用程序以合理的性能運行，瀏覽器供應商也不斷增加新的緩存和優化，這種日益復雜的功能引入了更多可能泄露歷史數據的接口，例如從 CSS 繪畫 API 到 JavaScript 字節碼緩存。
Background
瀏覽器對其用戶訪問的 URL 進行跟蹤，以便（1）幫助這些用戶識別他們已經訪問過的網站（例如，通過用不同的顏色標記熟悉的鏈接），以及（2）通過緩存資源以避免網絡請求來加快瀏覽速度。不幸的是，攻擊者可以利用這種保存狀態來了解用戶的私人瀏覽習慣。這種攻擊主要有兩類: Visited-link attacks 以及 Browser-cache attacks
Visited-link Attacks
通過 JavaScript ，開發者可以通過調用 getComputedStyle 方法來查詢任何元素的計算樣式屬性，該方法返回的數據如 {color: "purple"} 。瀏覽器還允許使用 :visited 選擇器為被訪問的鏈接設置任意的樣式，例如下面是一個例子，沒訪問過的鏈接是藍色，訪問過的鏈接是紫色。
/* Default link color to blue: */
a { color: blue; }
/* Turn visited links purple: */
a:visited { color: purple; }
根據鏈接的被訪問狀態，攻擊者可以用 CSS 改變其外觀，然后通過 JavaScript 觀察。
為了應對現實世界中的這種歷史嗅探攻擊，主要的瀏覽器采取了一對緩解措施。首先，他們通過限制 getComputedStyle 來解決顯性泄漏問題，即謊報鏈接的計算樣式：該方法現在總是返回鏈接的未訪問版本的樣式。其次，他們通過限制 :visited 的鏈接樣式的顏色來解決隱性泄露問題，這本應該是 JavaScript 無法獲取到的，所以瀏覽器應盡可能地緩存鏈接的計算樣式，而不是重新計算它們，以努力避免時間攻擊。除此之外，攻擊者仍然可以通過各式各樣的方法來獲取用戶歷史信息，例如使用互動任務（如驗證碼）來欺騙用戶披露歷史信息，從網絡攝像頭圖像的屏幕反射中推斷出鏈接的顏色等等。
Browser-cache Attacks
瀏覽器依靠許多層緩存來加快網絡應用；通過緩存HTML文檔或視頻等資源，瀏覽器可以避免在用戶第二次訪問頁面時重新獲取該資源的開銷。大多數瀏覽器只使用資源的 URL 來索引緩存條目，而不考慮嵌入資源的頁面的來源。這使得網絡攻擊者在 https://evil.com ，對 https://fb.com 進行跨源請求時，可以通過測量該請求的持續時間來了解用戶是否訪問過該網站。如果來自 https://fb.com 的資源已經在緩存中，則請求會更快；如果瀏覽器必須通過網絡獲取，則會更慢，如果目標資源足夠大，則會更慢。還有一些類似的瀏覽器功能，例如 App Cache 、 Service Worker 、 Quota management API 等，都可以被用來進行類似的攻擊。
Visited-link attacks on history
通過本章節，作者主要介紹了了三種針對被訪問鏈接的相關攻擊 ( Visited-link Attacks )，這些攻擊向攻擊者透露了用戶的瀏覽歷史。這些 "重繪 "攻擊分別利用了現代瀏覽器處理被訪問鏈接的一個基本漏洞：通過強迫瀏覽器根據鏈接的被訪問狀態重繪，并測量重繪事件發生的時間，攻擊者可以了解鏈接所指向的 URL 是否被訪問過。攻擊者可以檢測任意的、精確的URL的訪問狀態，包括路徑信息。此外，他們可以在不被受害者察覺的情況下做到這一點。
Abusing the CSS Paint API
作者展示了攻擊者如何使用 CSS Paint API 嗅探歷史數據。2018 年推出的 CSS Paint API 可以讓網站可以 Hook 瀏覽器的渲染進程 ( rendering pipline )，自己繪制 HTML 元素的一部分，例如，用重復的棋盤圖案填充網頁的背景，以適應任何窗口大小和顯示分辨率。通過檢測這些 Hook 何時被調用，攻擊者可以觀察到瀏覽器何時在頁面上重新繪制一個鏈接元素。
基于這個理論，在目標 URL 之間切換鏈接會導致鏈接在其訪問狀態發生變化時被重新繪制，因此攻擊者可以推斷出這些 URL 是否被訪問過。可以通過 CSS Paint API 來觀察一個URL是否被訪問，方法是：
- 制作一個鏈接元素，只有當其相關的 URL 被訪問時才會被重新繪制
- 使用一個時間通道（通過瀏覽器操作的時間泄露信息）來確定是否發生了重新繪制。假設一個攻擊者想確定受害者是否訪問過 https://ashleymadison.com ，首先，攻擊者選擇一個他們知道受害者沒有訪問過的假鏈接（例如，https://dummy.com；或一個隨機生成的URL）；然后，攻擊者創建一個指向假目標的鏈接元素，并將鏈接的背景圖像設置為由畫圖腳本渲染的圖像。
<a id="target" >link</a>
<style>
#target {background-image: paint(myEvilPainter);}
</style>
當瀏覽器最初繪制鏈接時，它將調用 myEvilPainter 作為回調。
之后，在一個正常的（非畫圖）腳本中，攻擊者將鏈接的目的地切換為實際的目標 URL （不改變顯示的鏈接文本）: target.。如果攻擊者隨機的、已知未訪問的 URL 和目標 URL 都沒有出現在受害者的歷史記錄中，那么該鏈接的訪問狀態就會開始為 false ，并且在切換鏈接 href 后保持這種狀態。然而，如果目標 URL 確實出現在受害者的歷史記錄中，那么鏈接的 visited 屬性就會變為 true ，從而導致鏈接元素的無效化，迫使瀏覽器重新繪畫鏈接，從而第二次調用 myEvilPainter 的繪畫回調。計算對繪畫回調可以告訴攻擊者目標 URL 是否被受害者訪問過：兩次調用表示已訪問過，一次調用表示未訪問過。
然而，計算這些調用是困難的，因為 paintlet 運行在自己獨立的上下文中，很著很多限制：它們不能進行網絡請求，不能與其他腳本通信，也不能使用大多數其他 JavaScript API 。此外，瀏覽器確保它們繪制的像素不能通過 JavaScript 讀回，甚至阻止 paintlet 在多次執行中保存狀態。盡管有這些限制，攻擊者還是可以使用事件循環計時通道來檢測瀏覽器的重新繪制。具體來說，在繪畫回調中，可以引入一個運行 20 毫秒的循環，并阻止 JavaScript 事件循環。由于事件循環是共享的，在頁面中運行的代碼可以直接觀察到這個
var start = performance.now();
// ... change link URL & block on paintlet's paint
// callback ...
var delta = performance.now() - start;
if (delta > threshold) {
alert('Victim visited Ashley Madison!');
}
較長的 delta 表明，從已知未訪問的網址到目標待檢測網址的變化引起了重新繪制，這反過來意味著受害者訪問了目標網址。并且，重新繪制并不是即時的，其會被加入到瀏覽器渲染 "下一幀 "的隊列當中，進而被處理。由于今天的瀏覽器以每秒 60 幀的速度渲染網頁，這就給重繪的速度設定了一個上限，因此，意味著該攻擊最理想情況下，最多每秒泄露 60 個 URL 。
接下來作者介紹了如何批量去檢測該類型，使用多個鏈接元素，每個元素都指向不同的目標URL。整個流程分為兩個階段：
- 記錄階段，使用一個 paintlet 來掃描目標 URL ，并通過使用
registerPaint函數來存儲它們的訪問狀態。 - 讀取階段，使用另一個 paintlet 來 "讀取 "訪問狀態位，并通過 CSS 隱蔽通道將它們傳達給一個正常的、非 paintlet 的攻擊者腳本。
在記錄階段，攻擊者首先為每個目標 URL 生成一個獨特的標識符串。與我們之前的攻擊一樣，攻擊者然后設置每個鏈接元素的背景，由 paintlet 渲染。但是，在這次攻擊中，繪畫回調不需要阻止事件循環，而是使用 registerPaint 將 paintlet 與一個新的標識符聯系起來：舊的標識符后綴為 _visited 。
paint (ctx, geometry, properties) {
// Get identifier (e.g., ashleyMadison):
var iden = properties.get('font-family');
// Associate this paintlet with tweaked
// identifier (e.g., ashleyMadison_visited):
registerPaint(`${iden}_visited`, ...);
}
通過將鏈接的 font-family 樣式設置為 URL 標識符，攻擊者可以向繪畫 callback 傳達重新繪畫是代表哪個URL運行的，在通過他們的鏈接元素集給所有目標 URL 批次標識后，攻擊者創建一個新的 paintlet 來檢查，對每個可能的標識符調用 registerPaint ，如果標識符已經被注冊了（在記錄階段），registerPaint 會拋出一個重復調用的異常， paintlet 會捕捉到這些異常，再為每個已經注冊的標識符注冊一個新的唯一標識符。
try {
// Try to associate identifier
// (e.g., ashleyMadison_visited):
registerPaint(iden, ...);
} catch (e) {
// Create new identifier from the old
// (e.g., ashleyMadison_exfiltrate):
var newIden = iden.replace('_visited', '_exfiltrate');
// Associate new identifier with paintlet:
registerPaint(newIden, ...);
}
接著，攻擊者使用 CSS Paint API 實現的一個功能來檢測這些新的注冊標識符，對每個可能的 *_exfiltrate 標識符都增加一個樣式，如：
#ashleyMadison_element::after
{ content: paint(ashleyMadison_exfiltrate); }
這段 CSS 代碼選擇了標識符為 ashleyMadison_element 的 HTML 元素，并插入了一個新的圖像元素作為其最后一個子元素。為了繪制這個圖像，內容規則規定，瀏覽器應該調用注冊為 ashleyMadison_exfiltrate 標識符的 paintlet 的回調。如果這個 painttlet 標識符剛剛被注冊，那么瀏覽器就會為子圖像元素計算一個大的寬度值；否則，如果 ashleyMadison_exfiltrate 不是剛剛注冊的，或者根本就沒有注冊，那么圖像元素的寬度就會變小，這樣攻擊者可以通過 *_element 元素進行循環，并檢查它們的寬度：一個大的寬度對應于一個用戶訪問過的 URL 。
作者提出的批量檢測效率在受害者不知情的情況下可以以每秒 3000 個 URL 的速度探測用戶的瀏覽歷史，也就是說，可以在 30-40 秒內掃描 Alexa Internet 的前10萬個網站列表，整個流程都處于后臺應用，對頁面沒有可見的影響，也不需要受害者的互動。Chrome 瀏覽器是唯一實現了 CSS Paint API 的瀏覽器，所以它也是唯一受此攻擊影響的瀏覽器；作者在 Windows、macOS 和 Ubuntu Linux 下的 Chrome 66.0.3359.117 上成功進行了攻擊。作為回應，谷歌將 CVE-2018-6137 分配給作者的報告，并獎勵了 2000 美元，他們為 Chrome 67 發布的補丁包括一個臨時修復，禁用了鏈接元素及其子元素上的 CSS Paint API 。
Abusing CSS 3D transforms
作者下一個攻擊是利用 CSS 的 3D 變換，開發者可以用它在三維空間中對 HTML 元素進行平移、旋轉、投影，甚至是動畫化。攻擊者將這些三維變換堆疊在其他 CSS 效果之上，通過創建一個鏈接元素，使受害者的瀏覽器難以繪制。然后，攻擊者在兩個不同的目標 URL 之間反復切換鏈接元素，并使用 :visited 選擇器迫使瀏覽器在鏈接改變訪問狀態時完成耗時巨大的重繪操作。通過這些操作進而泄露受害者是否訪問過目標 URL ，攻擊者通過 JavaScript 監控頁面的渲染性能來獲取這些信息。
如同前面所提到的一樣，檢測受害者是否訪問過目標連接，攻擊者首先創建一個指向已知未訪問過的假網址的鏈接。然后，攻擊者利用 CSS 三維變換和其他后處理效果來增加瀏覽器重新繪制鏈接時的負擔。經過作者的嘗試，最終得出了一個比較好的實驗設置如下，主要包括過濾、陰影和輪廓樣式：
#target {
transform: perspective(100px) rotateY(37deg);
filter:
contrast(200%)
drop-shadow(16px 16px 10px #fefefe)
saturate(200%);
text-shadow: 16px 16px 10px #fefffe;
outline-width: 24px;
font-size: 2px; text-align: center;
display: inline-block;
color: white;
background-color: white;
outline-color: white;
}
在作者的攻擊實現中，還用一長串隨機的中文字符來填充鏈接的顯示文本。
屬性的具體組合并不重要，重要的是攻擊者通過分層的計算密集型效果使瀏覽器難以呈現該元素。攻擊者想迫使受害者的瀏覽器在鏈接的訪問狀態改變時重新進行這些計算，現代瀏覽器在最初繪制鏈接時，會進行一次計算，盡管速度相對較慢，然后重新使用渲染的結果，除非鏈接的計算樣式發生變化。在這種情況下，改變鏈接的顏色意味著瀏覽器必須重做攻擊者在鏈接元素上應用的所有昂貴的轉換和后處理效果。因此，攻擊者可以為該鏈接寫了一個 :visited 樣式，為其visited 狀態為真時指定一組不同的顏色值。
a:visited {
color: #feffff;
background-color: #fffeff;
outline-color: #fffffe;
}
接下來，攻擊者通過 JavaScript 將鏈接的目標 URL 從 https://dummy.com 已知的、隨機得到的未訪問鏈接切換到https://ashleymadison.com 目標鏈接，當受害者訪問過 https://ashleymadison.com 時，改變鏈接的 href 后，它的訪問狀態從假變成了真，此時顏色也會發生變化；結果，受害者的瀏覽器必須用新的顏色從頭開始繪制該鏈接。這里特殊的顏色選擇使受害者在白色背景下看不到鏈接，而從白色到接近白色的變化也同樣難以察覺。這樣一來切換其訪問狀態會導致受害者的瀏覽器進行一次代價昂貴的計算，在完成計算的過程中耽誤頁面的渲染周期。反復該過程，在兩個 URL 之間來回切換，使包含頁面的性能明顯下降（但由于現代瀏覽器的并行、多進程架構，瀏覽器的其他部分或滾動的性能不會下降）。如果攻擊者測量到這種性能下降，他們就會知道他們的受害者是一個該網站的用戶。
有許多方法可以從 JavaScript 中完成這一工作。可以選擇使用 requestAnimationFrame API，這是一個旨在允許 JavaScript 代碼驅動流體動畫的API。當開發者向這個函數傳遞回調時，瀏覽器會在為頁面繪制下一幀之前調用該回調。瀏覽器的目標是每秒調用回調約 60 次（與頁面的整體幀率相同），但如果頁面的繪制性能下降，這個值就會略小。攻擊者可以利用這一點，進行兩次測量，每次都是在一個固定的時間窗口。首先，攻擊者可以在兩個不同的已知未訪問的假網址（例如，https://dummy.com 和 https://dummy2.com ）之間來回切換，通過循環注冊 requestAnimationFrame 的回調并記錄瀏覽器調用的次數來多次收集幀數，以此得到平均幀數 c 。然后，使用同樣的程序，攻擊者在目標URL https://ashleymadison.com 和已知未訪問的 URL 之間來回切換時進行實驗測量，得到平均幀數 e 。對比兩次的值，如果 e 明顯低于 c ，則反映了攻擊者第二次測試的繪畫性能下降，表明受害者已經訪問了 https://ashleymadison.com 。
作者發現該攻擊在最新版本的 Chrome、Firefox、Edge 和 Internet Explorer、Windows、macOS 和 Ubuntu Linux 中都是有效的。
Abusing fill-coloring of SVGs
此節與上述攻擊類似，只不過使用了更為復雜的 SVG 圖像應用，這樣的顏色更新對渲染引擎的代價來說是非常昂貴的。
攻擊者在一個鏈接元素中嵌入一個復雜的SVG圖像，并在 :visited 選擇器下設置一系列 CSS 填充規則，根據鏈接的訪問狀態為圖像的組件指定不同的顏色值。
<a > <svg xmlns="http://www.w3.org/2000/svg"> ... embedded SVG image data (verbose XML) ... </svg> </a>
在作者的攻擊中，我們構建了一個渲染成本極高的 SVG 圖像：該圖像由許多（7,000多個）復雜的路徑元素、充滿色彩的多邊形多層排列而成。接下來，攻擊者針對他們的 SVG 圖像設置了一系列的 CSS 填充規則，然后使用包含鏈接的 :visited 選擇器設置另一個樣式，當鏈接被訪問過，也就是 visited 狀態為真時應用一種顏色模式，否則就應用另一種樣式。
a svg * {fill: #ffffff;}
a svg *:nth-child(3n+1) {fill: #fffffe;}
a svg *:nth-child(3n+2) {fill: #fffeff;}
a:visited svg * {fill: #feffff;}
a:visited svg *:nth-child(3n+1) {fill: #fefffe;}
a:visited svg *:nth-child(3n+2) {fill: #fefeff;}
顏色值的選擇是為了使 SVG 圖像在白色背景上不可見，并且使兩種顏色模式之間的交換對受害者來說是不可見的。攻擊的其余部分與上文的 3D 旋轉完全相同：攻擊者使用 JavaScript 快速切換鏈接的目標 URL 或 :visited 樣式規則的顏色值，以便在他們選擇的目標URL（例如 https://ashleymadison.com ）被用戶訪問的情況下，強制進行許多昂貴的重新繪制操作。同時，攻擊者監控頁面的整體渲染性能（例如使用 requestAnimationFrame），并將其與控制測量進行比較，以推斷出URL的訪問狀態。
這種攻擊對 Chrome、Firefox、Edge 和 Internet Explorer 都很成功，可以在 100ms 的測量周期內進行訪問判斷（通常是 2 次回調調用與 5 次回調調用）。隨著時間窗口的增加，該差距越來越大（例如，在 1000ms 時， 9 次對比 41 次）。在這里，攻擊者也通過選擇與頁面背景相融合的顏色值，向受害者隱藏了攻擊中使用的元素。
Bytecode-cache attacks on history
在不同來源之間共享資源的瀏覽器優化（例如，緩存）可能會讓攻擊者探測這些資源，以尋找不同來源的頁面留下的痕跡。作者檢查了 Chrome 的 JavaScript 字節碼緩存（2015年添加），這個緩存保留了 JavaScript 引擎在編譯和運行腳本時產生的字節碼，如果以后需要再次執行該腳本， JavaScript 引擎可以使用緩存的字節碼而不是重新編譯該腳本。通過探測字節碼緩存，攻擊者可以可靠地確定受害者的瀏覽器以前是否執行過特定的腳本文件，從而推斷出受害者的瀏覽歷史細節。事實上，攻擊者甚至可以在受害者重啟瀏覽器或機器后檢測到過去的腳本執行情況，因為 Chrome 瀏覽器會將其字節碼緩存持續到磁盤上。
假設一個開發者在他們的網站上嵌入了腳本 foo.js ，當用戶訪問該開發者的網站時，他們的瀏覽器會下載 foo.js ，但瀏覽器不會立即開始執行它。瀏覽器必須首先解析 foo.js 中的 JavaScript 代碼（因為腳本是以源代碼形式發布的），然后將其編譯為適合驅動 JavaScript 引擎的字節碼。由于 JavaScript 靈活的語法和語義，這個最初的 "啟動" ( boot up ) 階段耗費了大量的時間。此外，如果開發者在其網站的多個頁面上嵌入 foo.js ，性能成本會越來越大，每次頁面加載，瀏覽器都要重復同樣的工作來啟動 foo.js 。所以 Chrome 瀏覽器通過其"字節碼緩存"優化避免了這種重復工作，該優化針對的是重復執行的、超過預定義大小閾值的腳本。如果 foo.js 符合這種描述，那么在第三次執行該腳本時， Chrome 的 JavaScript 引擎會將生成的字節碼存放在以 foo.js 的 URL 為關鍵的磁盤緩存條目中。在隨后的執行中， Chrome 會跳過通常的啟動階段，從緩存中讀取字節碼。
由于 Chrome 瀏覽器在不同來源的頁面之間共享每個腳本的字節碼緩存條目，攻擊者可以通過測量 Chrome 瀏覽器啟動特定腳本的時間來推斷歷史信息。舉個例子，攻擊者想知道他們的受害者是否訪問過https://ashleymadison.com。
。為了可靠地實現這一目標，攻擊者必須精確測量兩個時間點。(1) 瀏覽器完成下載腳本的時間；(2) 腳本開始運行的時間；這兩個時間點是編譯步驟的起點。攻擊者必須明確地避免測量瀏覽器在編譯前下載foo.js所花費的時間和編譯后執行的時間--這些數字根據許多因素（例如，受害者的網絡連接）而變化，因此會引入足夠的噪音來掩蓋相關的時間信號。為了追蹤第1點--當腳本完全下載時--攻擊者可以使用資源計時API，它為這個事件提供了一個時間戳[39]。對于第2點--當腳本開始運行時--瀏覽器沒有提供直接的測量手段。然而，攻擊者可以通過測量腳本首次設置全局變量的時間來估算腳本的啟動時間
- 攻擊者選擇一個由其主頁嵌入的腳本，例如，https://ashleymadison.com/foo.js 。所選的腳本要足夠大，以至于之前對該網站的訪問會導致受害者的瀏覽器為該腳本生成一個字節碼緩存條目。
- 然后，攻擊者在他們自己的頁面中 ( https://attacker.com ) 隱蔽地嵌入一個指向該URL的腳本標簽，例如
<script src="https://ashleymadison.com/foo.js"></script> - 當受害者訪問 https://attacker.com ，Chrome會下載、編譯并執行 foo.js ，如果能在字節碼緩存中找到 https://ashleymadison.com/foo.js ，瀏覽器會跳過編譯的步驟。在這種情況下， foo.js 從下載到運行的時間大大少于其他情況（大約幾十毫秒；見下圖）
- 通過測量這個時間差，攻擊者可以推斷出受害者是否訪問了 https://ashleymadison.com 。
每次執行雅虎主頁中的 JS 腳本所用的啟動時間。在第三次執行該腳本后 Chrome 的 JavaScript 引擎會創建一個緩存條目。顯示的時間是10次試驗的平均數。
因此，在實施攻擊之前，攻擊者必須確定 foo.js 設置的第一個全局變量的名稱。為此，攻擊者記錄了 JavaScript 全局范圍內的所有變量列表，即窗口對象。接下來，他們注入一個指向 foo.js 的腳本標簽，指示瀏覽器（1）加載和執行目標腳本，然后（2）回調到他們自己的代碼，即 loadCallback 函數。在 loadCallback 函數中，攻擊者生成了一個新的全局變量列表，并將這個列表與 oldGlobals 進行比較，以確定 foo.js 設置的第一個全局變量的名稱。
var oldGlobals = Object.keys(window);
var scriptTag = document.createElement('script');
scriptTag.async = false;
scriptTag.src = 'https://ashleymadison.com/foo.js';
scriptTag.addEventListener('load', loadCallback);
document.head.appendChild(scriptTag);
在攻擊階段，攻擊者定義了一個 setter 函數，只要 foo.js 設置了這個全局變量，就會調用該函數。這個函數只是在第一次調用時記錄當前時間，腳本開始運行的大致時間。攻擊者使用這個時間戳和下載時間戳來計算腳本的啟動時間，并將其與參考測量值進行比較，以推斷腳本字節碼是否先前被緩存。如圖2所示，字節碼緩存可以使啟動時間加快 2.5 倍 - 10 倍，使攻擊者很容易推斷出受害者之前是否訪問過目標網站。
作者發現這種攻擊對 Windows 、 macOS 和 Linux 版本的 Chrome 瀏覽器有效。該攻擊需要大約 100ms 的時間來檢測目標腳本 URL 的字節碼緩存命中或未命中，并且可以多次并行地對目標列表的緩存進行批量查詢。攻擊者可以通過更聰明地選擇目標腳本來了解受害者的更多信息，例如，測試那些只在網站的登錄頁面才會加載的腳本。
在自動掃描中，我們確認在前 500 個網站中的 372 個（74%）存在一個合適的目標腳本——在壓縮前大小為 100KB 或更大。作者認為這是最保守估計的結果，因為他們只掃描每個網站的HTML源靜態嵌入的腳本文件。出于性能方面的考慮，一些網站會在初始頁面加載后動態地注入它們的腳本；盡管字節碼緩存條目仍會為這些腳本生成，并且攻擊不需要修改就能發揮作用，但他們的掃描工具還不能檢測到動態注入的腳本。此外，剩下的大約 32 個被檢測為不可攻擊的網站要么是不提供網頁服務的 CDN 域名，要么是有證書錯誤，無法測試。
與對其他網絡資源類型（如圖像）的緩存定時攻擊相比，這種攻擊更實用，因為它消除了一些干擾因素（如來自網絡的變化）。此外，產生可檢測的時間差異所需的文件大小閾值要小得多，使攻擊者能夠針對廣泛的網站測試。與大多數歷史偵查緩存計時攻擊一樣，這種攻擊是破壞性的：查詢字節碼緩存條目的過程中，如果該條目不存在，就會強制創建該條目。這意味著該攻擊不能針對同一受害者的同一腳本 URL 重復進行。
Consequences and defense
作者在三種操作系統（ Windows、macOS 和 Ubuntu Linux ）上的 Chrome 和 Firefox 中進行了測試，并在 Edge 和 Internet Explorer 中進行了測試。本文介紹的這兩類攻擊( CSS Paint API 攻擊和字節碼緩存攻擊)，只影響 Chrome ，因為它們的目標是其他瀏覽器尚未實現的功能。另外兩種攻擊，涉及 CSS 三維變換和 SVG 填充著色使用了更多的傳統功能，并且證明在所有這四種瀏覽器中都有效。最后，作為比較，作者測試了 Paul Stone 的 visited-link 攻擊的兩個獨立實現，發現它只在 macOS 和 Linux 的 Firefox 中成功，如前所述。除了測試主要瀏覽器的原始版本外，我們還評估了我們對這些啟用了額外隱私功能的瀏覽器的攻擊，以及對幾個面向隱私的瀏覽器的攻擊：
- Chrome with Site Isolation. 站點隔離 ( Site Isolation ) 將每個站點的數據限制在獨立的進程中，但沒有對
:visited選擇器或字節碼緩存施加任何限制，它們保持共享。因此，這一特性并不能阻止本文介紹的攻擊。 - ChromeZero research extension. ChromeZero 試圖通過限制某些 JavaScript APIs 來阻撓攻擊者，但是由于本文的攻擊并不依賴這些API，因此即使擴展程序處于最高保護模式，它們仍然可以發揮作用。
- Brave. Brave 是一個面向安全和隱私的瀏覽器，但由于 Brave 是建立在 Chromium 之上，作者發現它容易受到與 Chrome 相同的攻擊。
- Firefox with visited links disabled. 禁用 Firefox 的
layout.css.visited links enabled配置標志本應可以完全消除 Visited-links Attacks 的影響，但事實并非如此：禁用該標記既不能阻止本文的 Visited-link Attacks ，也不能阻止 Paul Stone 之前提出的攻擊，作者也向 Mozilla 報告了這個錯誤。 - The Tor Browser. 這個火狐瀏覽器的發行版沒有記錄用戶歷史，因此對我們的攻擊是免疫的。
- The FuzzyFox and DeterFox research browsers. 這兩個修改版的火狐瀏覽器通過減小顯性、隱性計時器的精度來規避側信道；FuzzyFox 還對瀏覽器事件的安排進行了規范化處理。本文介紹的攻擊與其他對 Firefox 的攻擊仍然有效，因為它們不依賴于計時器的精度，但 FuzzyFox 會使本文的攻擊效率降低 10 倍左右。
Defense
為了解決反復出現的違反同源政策的問題，像 Mozilla 這樣的瀏覽器重構了他們的瀏覽器架構來加強 SOP 策略。作者認為，他們應該同樣地重組瀏覽器以解決類似的歷史嗅探攻擊。為此，作者提出了一個涵蓋持久性數據的同源性政策：瀏覽器在存儲資源時不應該只使用資源的 URL ，還應該關聯代碼所代表的頁面的來源。例如，任何歷史記錄都應標明引用頁面的來源，每個字節碼緩存條目都應標明嵌入相應腳本的頁面的來源，等等。因此，在獲取存儲數據時，瀏覽器應該檢查執行查詢的頁面的來源，只有在該來源與存儲數據相關的 referrer-origin 相同時才會成功。
當然，這種防御會產生一些成本。對于字節碼緩存來說，在每個站點上初始加載一個腳本會付出緩存丟失的代價，但隨后的頁面加載仍然會從緩存中受益。為了解決這個問題，作者設想了一個跨站點資源共享（CORS）的擴展，允許流行的公共資源（例如 jQuery ）在站點之間安全共享。其提出的防御措施也部分地打破了網絡兼容性，具體來說，CSS 中的 :visited選擇器將只準確地表示鏈接是否被來自同一來源的頁面點擊過。但是，瀏覽器之前已經破壞了隱私的兼容性：例如，對最初的 :visited 泄漏的修復改變了 getComputedStyle API 以返回不正確的信息，并破壞了使用 :visited 的現有樣式表。
