瀏覽器緩存污染防御策略

戴成瑞，陳 偉

(南京郵電大學 計算機學院，南京 210023)

0 引言

瀏覽器緩存可以節約網絡資源加速瀏覽，瀏覽器在用戶磁盤上對最近請求過的資源進行緩存，當訪問者再次請求這個頁面時，瀏覽器就可以從本地磁盤調用該緩存資源，這樣就可以加速頁面的閱覽。

瀏覽器緩存[1]主要包括Web緩存和HTML5應用程序緩存[2]。一般網絡上的資源都是默認利用Web緩存方式進行緩存，隨著網絡生活的高速發展，人們在使用瀏覽器上網時會瀏覽各種各樣的資源文件，而這些資源文件又分為靜態資源文件和動態資源文件：靜態資源文件是指圖片、CSS文件等，這些文件在較長的時間內都不會發生變化；而動態資源文件通常是指經常變化的JS文件，當然有些JS文件屬于變化較少的，通常這類文件容易遭受緩存污染攻擊[3]。

攻擊者可以通過中間人攻擊、被動抓包等方式污染用戶緩存，而傳統的緩存污染防御方案僅僅是針對某一具體的攻擊行為，本文希望設計一種可以不用關心攻擊者采用何種緩存污染攻擊方式的防御策略，對將要直接從緩存讀取的資源通過特征分析、用戶行為分析等多個步驟來判斷該資源是否具有被污染的可能性，最終保證用戶請求資源的安全性和體驗性。

本文首先分析并研究了目前常用的緩存污染攻擊方式，然后對傳統的緩存污染防御方案進行分析，在指出傳統防御方案存在不足的基礎上，提出一種無需關心攻擊者污染方式的防御方案，能夠自適應防御瀏覽器緩存污染，最后分析了本文所提出的防御方案的局限性，對今后的工作進行展望。

1 相關工作

緩存污染主要是一種污染用戶緩存的網絡攻擊手段[4]。這種緩存可以是域名系統(Domain Name System, DNS)緩存[5]、內容分發網絡(Content Delivery Network, CDN)緩存或者說本文所討論的瀏覽器緩存，就瀏覽器緩存污染研究而言，主要包括對污染攻擊的方法、防御和危害分析[6]這幾個方面。

Vallentin等[7]在介紹中間人攻擊的手段來實施緩存污染攻擊的同時，還提出了一種被動抓包偵聽的方式來實施緩存污染攻擊。Jia等[8]在介紹常規的HTTP瀏覽器緩存污染攻擊的同時，介紹了對HTTPS下實施緩存污染攻擊的方式，還提出了同源攻擊、跨源攻擊和瀏覽器插件攻擊三種攻擊手段。Vallentin等[6]等對一個真實的網絡環境進行了緩存污染攻擊，并介紹了如何利用最小的污染成本來實現最大化的攻擊范圍并定量分析了緩存污染的危害性。因此從上述的研究成果來看，對污染攻擊的方法已經有了較為全面的介紹，但是從防御的角度，大都是從用戶出發，提出經常清理緩存的建議。本文所介紹的防御策略是一種在用戶與服務器之間的一種可調控防御策略，這種策略的最大優勢在于不關注用戶是否被污染，或者說攻擊者使用何種方法進行瀏覽器緩存污染，簡化了緩存污染防御的流程，且能夠在安全性和用戶體驗性之間進行合理的平衡以滿足不同用戶的使用需求。

從之前研究結果來看，大部分用戶都沒有定期清理緩存的習慣，甚至處于一個中間人攻擊環境[9]也沒有一個良好的安全意識，使得各種各樣的緩存污染成為可能，而這又往往會成為其他網絡攻擊的跳板，危害極大[10]。本文所做的研究工作一方面希望能提高人們的安全意識，另一方面提出一種能夠抵抗絕大多數的緩存污染攻擊的防御策略，既不影響用戶正常瀏覽網頁的體驗性，又可以提高在復雜網絡環境下的安全性。

2 緩存污染攻擊

瀏覽器緩存污染[11]是指在攻擊者攻擊受害者瀏覽器期間，返回給瀏覽器具有潛在威脅的緩存資源，當受害者脫離攻擊者攻擊環境并再次上網請求資源時，瀏覽器直接從緩存中讀取已被攻擊者污染的資源從而受到污染攻擊。

就目前的研究工作而言，國內外對緩存污染攻擊方式有了較為全面的研究，最常用的攻擊模式就是利用中間人攻擊[12]，替換服務器返回給受害者的資源文件，不僅將返回數據包頭部中的緩存時間設置成很長的時間，還在返回數據包的內容里加上攻擊者想要在受害者機器上執行的代碼，常用的攻擊模式如圖1所示。

Vallentin等[7]還提出了一種不使用中間人攻擊的方式進行緩存污染攻擊，只需監聽無線網絡并利用重定向技術即可，雖然同樣處于服務器和受害者中間，但是攻擊者通過監聽網絡中的數據幀，并自行構造響應數據幀來干擾受害者，使受害者瀏覽器緩存了攻擊者想要污染的內容。

圖1 常用緩存污染攻擊圖 Fig. 1 Common cache pollution attack

之前討論的攻擊都是針對HTTP下的緩存污染[8]，因為在HTTP下通信雙方是沒有加密的，很容易搭建一個中間人攻擊環境，而Jia等[8]介紹了一種HTTPS下實施緩存污染攻擊的方法，其中在HTTPS下能實施緩存污染攻擊最主要的原因在于，對于大部分用戶，在面對瀏覽器提示某個網站證書有誤，確認是否繼續訪問時，他們仍然會點擊繼續訪問。他們提出了同源攻擊、跨源攻擊和瀏覽器插件攻擊三種手段來進行HTTPS下的緩存污染攻擊。

針對緩存污染防御方面，正如前面篇幅所述，HTTPS本身是可以抵御一定的瀏覽器緩存污染的，推薦站點盡可能使用HTTPS協議進行通信，但用戶缺乏安全意識的話HTTPS也不是那么可靠，這種情況下推薦使用HTTP嚴格傳輸協議(HTTP Strict Transport Security, HSTS)，只要用戶第一次訪問了合法的站點，瀏覽器在很長的時間里都只能用HTTPS訪問該站點，可以較好地防御流量劫持。然而面對這樣的防御手段，攻擊者仍然可以通過跨源攻擊的方式實施緩存污染攻擊：當用戶訪問網站1時，攻擊者故意加載網站2的資源，這個攻擊手段的意義在于網站1若是某個新聞網站(不涉及用戶敏感信息)，而網站2是某個在線銀行網站(具有敏感信息)，即使瀏覽器彈出證書不可信的提示，但是用戶仍然會以較大概率點擊繼續訪問，然而背后加載的卻是網站2的資源。

Jia等[8]還提出一種同源策略，因為對于某個JS資源A也許會被不同網站調用，瀏覽器可以記錄是向網站1請求的資源A還是向網站2請求的資源A，這樣可以防止跨源緩存污染攻擊。這種防御方式的弱點在于攻擊者可以采用瀏覽器插件攻擊，因為部分瀏覽器插件通常也含有一些腳本文件，污染瀏覽器插件的意義在于插件是屬于瀏覽器的，不管訪問哪個網站，都會觸發緩存污染攻擊。

其實對于瀏覽器來說，如果發現某個服務器證書不可信，那么就不要緩存該服務器下的資源。對于用戶來說，最簡單直接的緩存污染攻擊防御策略就是不要訪問不受信任的網站，并且養成定期清理緩存的好習慣，增強安全意識。

因此，在已有的一些緩存污染應對方法出現的情況下，本文開展研究的目的是上述介紹的任何瀏覽器緩存污染防御方式都無法應對多種多樣的網絡攻擊，防御中間人攻擊帶來的緩存污染，攻擊者仍可以使用被動抓包、流量注入等方式達到目的，很難找到一個應對多種攻擊模式的防御策略，而這真正的問題在于大部分研究僅僅關注如何防止用戶緩存被污染，而忽視了緩存污染攻擊的觸發條件即用戶下次請求資源時直接讀取被污染的緩存。因此本文研究的核心是即使用戶緩存被污染，也能通過一些手段將其檢測并恢復出來，這樣防御策略可以直接跳過判斷用戶此時是否遭受同源攻擊、跨源攻擊、流量注入等緩存污染攻擊的步驟，從而用單一的防御策略應對多種多樣的攻擊模式。

無論是用何種方式污染了受害者瀏覽器下的緩存[13]，當受害者脫離了攻擊者搭建的攻擊環境，由于受害者計算機中的緩存資源已經被污染，仍然會面臨著潛在的威脅；而這種威脅是未知的，如果用戶不及時清除自己的緩存，這樣的威脅也許會持續一個月，甚至更久，而且往往緩存污染攻擊可以當作很多網絡攻擊的跳板來作出更具有侵害性的行為[14]。因此，提出一種流程簡單但能應對多種緩存污染攻擊方式的防御方案具有重要的實際意義。

3 瀏覽器緩存污染防御方案

無論采取何種方式進行緩存污染攻擊，攻擊者的目的都是一樣的：污染用戶的緩存[15]。因此本文所討論的防御方案并不關注防御攻擊本身，而是在于及時檢測出被污染的緩存并進行恢復。即使用戶的緩存被污染，當用戶在后續的訪問中，我們能及時檢測到被污染的資源使之重新加載成正確的資源，同時又能保證未被污染的緩存資源能夠順利從用戶瀏覽器緩存中讀取，總的來說，本文所討論的防御方案是在保證用戶正常瀏覽網頁的情況下，既不影響到用戶體驗性，又能實現安全的保障。

本文所討論的防御端處于用戶與服務器之間，該防御策略理想化的實驗結果就是一方面將所有未被污染的緩存資源直接作讀取緩存處理；另一方面使所有被污染的緩存資源都能夠被防御腳本檢測出來，并且重新向服務器請求真實的資源返回給用戶。

因此本文所設計的防御策略總體思路就是在用戶請求緩存資源時，逐步根據緩存資源特征判斷該資源是否是未被污染的：一旦在判斷過程中認為該資源是未被污染的就作直接讀取緩存處理；當經過所有的判斷該資源仍無法決定，就認為該資源是被污染的，需要重新向服務器請求該資源。這么做的目的在于盡快地判斷出該資源是否應該直接讀取緩存，從而最大限度上減小防御策略判斷過程中帶來的時間消耗。

整個判斷策略過程是一個從粗略到細致的過程，剛開始的判斷僅僅是分析該資源是否要從緩存中讀取，不讀緩存的資源就相當于從服務器重新請求資源。真正具有潛在威脅的是準備讀取緩存的資源，針對這部分資源，該防御策略通過用戶的行為特征和資源本身的通用度進一步決策出是否被污染；對于仍無法判斷的資源需要進行最后的哈希驗證，這是檢測資源是否被污染最為有效也是最耗時的方法，一旦驗證不成功就拒絕該資源并向服務器重新加載新的資源。3.1～3.7節將闡述具體的防御策略。

3.1 隨機數判斷

如果用戶請求的統一資源定位符(Uniform Resource Locator, URL)后面含有隨機數，那么代表該資源是直接向服務器請求最新的資源，無需進行后續的判斷，防御端不作處理，因為這樣請求的資源一定是服務器上真實的資源，不存在被污染的可能性。

3.2 請求響應延時判斷

如果用戶請求的資源URL后面沒有包含隨機數，那么該資源是有可能受到污染的，因此這里需要計算用戶請求該資源的時間和服務器返回的時間差：如果該時間差超過了某個閾值Te，則認為該資源之前是沒有被緩存到用戶瀏覽器上，自然也不需要重新申請該資源；如果該時間插值小于該閾值，則此資源需要進一步判斷是否被污染。

這里的閾值Te可以在防御端啟動時進行初始化檢測，因為對于不同的網絡環境，這個閾值Te是不一致的，同時，用戶在上網的過程中，也有可能面臨網速的變化，因此防御端對于閾值Te的檢測是周期性的。

3.3 資源代表性判斷

進入此步驟的資源由于請求返回時間差小于閾值Te，因此都是將要直接讀取用戶瀏覽器緩存的。這里為了進一步優化用戶的體驗性，需要定義并計算資源代表性值C，因為對于大部分的緩存污染攻擊模式，攻擊者利用中間人攻擊的手段不滿足僅僅污染用戶請求的資源，而是使用預加載通用資源至用戶端的方式，導致用戶緩存資源雖然沒有被大面積污染，但是卻能以很高的概率被觸發。因此攻擊者使用的通用資源必然是具有代表性的，所以當用戶請求的資源是處于不常訪問的或者說之前根本沒有訪問的，那么我們大概率推測該資源是沒有被污染的，可以直接返回給用戶。

此時定義資源代表性值C，該值由用戶行為值U與Alexa[16]統計值A累加得出。其中：用戶行為值U是根據用戶上網的習慣所給出的評價值，范圍是[0,1]；Alexa統計值A是根據Alexa網站統計排名所給出的值，范圍同樣是[0,1]。當資源代表性值C小于閾值Tc時，那么認為該資源是非通用資源，不容易成為攻擊者攻擊的目標，這些資源直接返回給用戶；當C大于閾值Tc時，將交由下一步判斷。

這里的閾值Tc同樣可調控：如果想要追求更大的安全性，閾值Tc應該設置足夠地小，讓更多的資源進行下一步的判斷；如果想要更好的用戶體驗，可以提高閾值Tc。

3.4 哈希驗證

不論攻擊者利用什么手段污染了用戶的某個資源，該資源與服務器上原始資源的哈希值是不同的。基于此，考慮到防御端無需占用太大的空間，防御端事先以鍵值對的形式存儲好常用的資源名所對應的該資源內容的哈希值，同時可以搭建一個防御端服務器存儲更多這樣的鍵值對便于查詢。進入到該步驟下的資源，如果所計算返回資源的哈希值和防御端中已存放對應的哈希值一致，直接返回給用戶；如果不一致，說明該資源被污染，防御端重新向服務器請求最新的資源給用戶；如果沒有查詢到，訪問防御端服務器查詢并進行同樣的操作。當服務器端也查詢不到時，直接向服務器請求真正的資源返回給用戶，因為即使該資源是未被污染的，重新向服務器請求真正資源并計算哈希值比對也是沒有意義的，所以這里直接當作被污染的資源處理。

3.5 眾包策略

這里值得注意的是，真正的資源文件也是會變化的，當遠程服務器的資源文件發生變化，而防御端還沒即時更新，此時檢測哈希值必然是不一致的，防御策略會將這樣的資源當作污染資源處理，因此，當防御端所監測的用戶群在某個時間開始，針對某個資源的哈希值出現大量的不一致且這些計算的哈希值都為同一值時，將進行自適應的調整，以保證防御端能夠存放著不斷更新的鍵值對。

當然，眾包策略需要大量用戶參與才能保證眾包的可靠性，例如當防御系統充當校園網管角色時，大量校園用戶與遠程服務器的交互會使系統不斷處于一個自動更新的狀態，而當只有少量用戶參與，該防御系統并不能做到有效的快速更新，更多依賴的是系統本身定期向各個服務器來獲取最新的數據。

3.6 相關假設

在用戶依賴這樣的防御策略情況下，需要保證當防御腳本檢測出污染資源時向服務器請求的最新資源是未被污染的。如果用戶已經脫離攻擊環境，顯然向服務器重新請求資源是安全的；而用戶仍若處于中間人攻擊這樣環境，此時很難利用該防御策略抵御緩存污染攻擊，因為就算服務器返回的資源是未被污染的，攻擊者仍可以采用中間人的方式替換資源。這里涉及到的關鍵問題在于中間人攻擊的防御，并不在本文討論的范疇。本文所介紹的防御策略就是讓資源可以被緩存污染，但是在下次觸發緩存污染時能夠有效檢測并恢復。

3.7 防御策略算法

本文所介紹的防御端是處于用戶與服務器之間，換句話說，它既可以充當某個校園網管的角色進行緩存污染保護，也可以運行在用戶機上針對具體的用戶進行防護。為了便于進行實驗和結果分析，將中間人代理方式構建在用戶機上，當用戶在瀏覽器設置里添加Node.js所監聽的端口以及代理服務器地址(這里就是127.0.0.1)，那么之后這樣的一個簡單的代理首先能夠接收客戶端的轉發請求，并且根據客戶端請求向真正目標服務器發起請求，最后再將真正的服務器響應內容轉發給客戶端。

在搭建了這樣一個中間人代理之后，按照上一章節所介紹的防御策略設計相應的算法實現。其中對于資源代表性判斷算法，由于涉及到兩種不同范圍的值的運算，所以需要對數據作歸一化處理，對于用戶行為值U，采集用戶的歷史瀏覽紀錄并按照訪問次數大小排序如下所示：

[x1:u1],[x2:u2],…,[xn:un]

xi(i=1,2,…,n)代表資源名，無論用戶使用HTTP協議還是HTTPS(SSL/TLS)協議，提取用戶在一段時間內請求的資源名，作為用戶行為值判斷的樣本。ui(i=1,2,…,n)代表資源xi的訪問次數，總共有n對這樣的數據，其中u1≥u2≥…≥un，因此如果對于資源xj，那么歸一化的計算公式為：

針對u1=un這種情況，無需使用歸一化對用戶行為值進行處理，因為該條件代表用戶歷史瀏覽記錄中不同資源的請求次數都是一致的，此時用戶行為值U是無意義的參數，無法判斷該資源在歷史記錄中的流行程度。因此只需考慮另一種判斷因素也就是Alexa統計值A，本文參考的是Alexa網站流量全球綜合排名[16]，這是一種更具有普適意義的系數，與上述數據不同的是，這里按照如下方式采集數據：

[y1:m],[y2:m-1],…,[ym:1]

最后根據系數W按如下公式計算c：

隨著時間的推移，用戶行為值U與Alexa[16]統計值A都會發生變化，雖然一些變量在初始化的時候生成，但是在后續的防御過程中會周期性地檢查以確保防御端處于一個不斷更新的狀態。考慮到上一時刻的ci-1仍然對當前時刻的ci具有一定的影響，一個合理的計算公式為：

ci=t*ci-1+(1-t)*ci

t是上一時刻的ci-1對當前時刻的ci的影響因子，處于0～1，通過這樣不斷的迭代，c會不斷地根據上一時刻更新到這一時刻從而與閾值Tc相比較。這些變量和值如表1所示。

4 實驗及結果

4.1 緩存污染攻擊模擬實驗

本文基于Node.js模擬中間人攻擊的方式，對用戶進行緩存污染攻擊模擬實驗。

4.1.1 搭建環境

用戶處于一個中間人攻擊環境[17]或者連上攻擊者創建的無線網絡接入點。這一步主要是為了構建一個網絡攻擊環境，本文具體采用Node.js中的express框架，監聽本機的8080端口。實驗進行時，用戶將瀏覽器的代理服務器設置成127.0.0.1，同時代理端口設置為8080，接下來用戶通過瀏覽器發出的請求都會被監聽腳本捕獲。

4.1.2 選取待污染的資源

在這一部分的實驗中，盡可能地模擬攻擊者的行為，從攻擊者的角度出發，如何選取合適的資源來污染是這一步的關鍵。首先創建一個URL的列表文件，上面列舉著一些常用的網站域名，再基于PhatomJS模擬請求這些網站，根據網站返回資源信息，去提取出帶污染的資源URL。具體的選取規則依賴于HTTP頭部特征，本文根據資源頭部信息里的緩存時間、緩存過期時間、上次修改時間和是否具有ETag標志這四個特征判斷這個資源是不是容易被污染的。即使用戶進行刷新操作，瀏覽器也不會向服務器請求完整的資源，而是詢問服務器該資源是否被修改過，若沒有修改過，那瀏覽器仍然從緩存中讀取該資源，因此選取這些待污染的資源能有效避免用戶刷新頁面導致緩存污染攻擊失敗的問題。

4.1.3 實施緩存污染

用戶正常瀏覽網頁，當攻擊腳本監聽到用戶在訪問HTTP的網站時，嘗試預加載上述待污染的資源，利用發送帶隨機數的URL請求真正的資源并加上模擬攻擊代碼，那么上述選取的待污染資源內容其實都被篡改，即在保證顯示原有頁面的情況下彈出一個模擬攻擊窗口，同時設置資源的緩存時間為31 536 000 s以及其他的頭部信息。

4.2 實驗結果分析

此時用戶的瀏覽器緩存里會被強行緩存了攻擊者設置好的資源，這些資源往往具有很高的通用性，也許用戶這一時刻并不會打開，但是這些資源都被設置了很長的緩存時間，并且這些資源在服務器上距離上次修改也隔了很長的時間，大概率推測將來的一段時間也不會頻繁地變動，因此即使用戶脫離攻擊環境，只要之后沒有清空緩存，那么該資源很容易被觸發，一旦請求了該資源，瀏覽器會從緩存中直接讀取，而緩存已經被污染，所以用戶將會執行攻擊者的代碼。

在分析實驗結果之前需要定義污染樣本的命中率和正常樣本的誤判率。命中率是用來衡量該防御腳本的安全性，命中率越高說明有更多的污染樣本被防御腳本檢測出來，用戶通過直接加載緩存的方式請求資源而觸發緩存污染的概率也就越低，因此實驗的目標就是要將防御腳本的命中率接近100%；誤判率指的是防御腳本將正常樣本檢測為污染樣本的概率，誤判率越高說明防御腳本會讓用戶重新加載本應該直接讀取緩存的正常資源，因此必然會帶來時間上的多余消耗，從而影響到了用戶體驗性。對于個人用戶而言，也許重新加載資源所帶來的多余延時影響并不大，為了保證不漏判任何的污染樣本，必然要對用戶體驗性方面做出犧牲，換句話說就是在處理難以判斷的樣本時盡量當作污染樣本處理，來換取足夠高的安全性，因為攻擊者往往利用緩存污染作為跳板實施網絡攻擊，觸發緩存污染的危害是難以預估的；而對于校園網管的角色來說，往往會處理許多用戶的大量請求，需要權衡安全性和用戶體驗性，而該防御策略在兩者之間可以通過參數調控的。

采用預加載的形式使用戶瀏覽器緩存了攻擊者想要緩存的資源共1 000條，接著讓用戶脫離攻擊環境并運行本文所介紹的防御端腳本，當用戶請求其中100條被污染的資源和100條正常的資源，統計該防御策略在松弛條件和嚴格條件下能實現多少的命中率和誤判率，同時與不開啟瀏覽器緩存污染防御腳本和將所有資源都重新加載進行比較，最后統計上述四種方案的請求響應延時，實驗結果如表2所示。

表2 實驗結果Tab. 2 Experimental results

由表2所示，很容易理解未使用防御策略和全部重新加載在污染樣本命中率和正常樣本誤判率的表現，而另外的兩種是采用不同程度的緩存污染防御策略，相比而言，嚴格的防御策略下很多資源的URL交由哈希驗證處理，因此會存在部分查詢不到導致誤判率增加，同時耗時相對于松弛條件略有增加。

不難看出利用緩存污染防御策略相對于未使用防御策略的，能保持一個較好的安全性，同時還可以在可調控的范圍內以較低的請求響應延時進行工作。

4.3 緩存污染防御策略的優勢

首先緩存污染防御是一個處于用戶和服務器之間的防御手段，不受Web開發者、服務器、瀏覽器限制。傳統的瀏覽器緩存污染防御措施主要防止用戶遭受污染攻擊，Jia等[8]在介紹同源緩存污染攻擊手段時提出了利用HTTPS來防止中間人緩存污染攻擊，然而攻擊者仍可以利用跨源的緩存污染攻擊來削弱HTTPS的安全性，隨后便提出一種同源策略來應對跨源攻擊，即使這樣，攻擊者仍可以采用污染瀏覽器插件腳本的方式來實施污染攻擊，因為瀏覽器插件是屬于瀏覽器本身的而非某個網站，只要污染了插件訪問任何網站都會遭受攻擊。當用戶設法采取各種各樣的措施來防止中間人這種方式的緩存污染攻擊時，攻擊者仍可以采用Vallentin等[7]所介紹的流量注入方式污染用戶的緩存。

由此發現，攻擊者的攻擊模式是多樣的，而傳統的防御措施僅僅是考慮了如何防御用戶被污染，一旦新攻擊方式出現，那么傳統的防御方案就會失效，而本文提出的防御策略不關注緩存污染攻擊的方式，即使用戶遭受了污染攻擊，在后續的請求流量過程中該防御策略仍能檢測并恢復正確的資源文件。

在用戶體驗、服務器帶寬和安全性之間提出了一種可調控的平衡方案。防御方案中使用了用戶歷史行為進行輔助判斷以便提高響應速率。防御方案中的響應時間閾值、資源代表性值都可以通過當前網絡環境進行動態判斷，以增強實用性。本方案不關注資源是否被污染，或者說攻擊者使用何種方法進行Web緩存污染[18]，簡化了緩存污染防御的流程，將防御重心放在用戶的整個請求過程，既保證了安全性，又不影響用戶的體驗性，同時還不增加服務器端的壓力。

5 今后的工作

本文所介紹的防御端是處于用戶與服務器之間，并且假設此時用戶已經脫離了攻擊環境，這是為了保證防御端向服務器端請求資源是未被污染的，如果攻擊者處于防御端和服務器之間，這樣的防御策略很有可能失效了，因此，接下來的工作是在這樣的環境下進行一種實時的防護，尤其是當用戶從一個常規的IP地址突變到了一個非常規的IP地址，例如咖啡廳、快餐店等布置的公共網絡，該防御系統需要進入一個更高的安全檢測級別[20]，對于敏感的URL可以考慮在請求頭部加上不緩存的模式，防止攻擊者乘虛而入。

眾包策略依賴大量用戶的參與，如何判斷用戶量已經達到了可以開啟眾包策略進行實時更新的條件是接下來需要考慮的問題，但同時這樣的策略也容易遭受女巫攻擊，攻擊者可以偽造大量的節點共同請求污染的資源導致防御系統產生錯誤的更新而帶來安全隱患，因此接下來需要對訪問防御端服務器的用戶進行驗證。以校園網管的角色來說，學生可以按照自己唯一的學號去生成相應的數字證書，從而限制非法用戶偽造大量節點的請求。

同時，接下來的工作還應包括對用戶行為的詳細分析與預測，因為對于不同的用戶來說，他們的訪問習慣也是不同的，因此在他們的瀏覽器緩存中應該存放著體現各自上網習慣的信息，所以，要想實現更高的污染樣本命中率和更低的正常樣本誤判率需要將本文已經進行的工作與用戶行為分析[21]工作相結合。

6 結語

本文提出一種在用戶與服務器之間的緩存污染防御策略，通過隨機數判斷、請求相應延時判斷、資源代表性判斷、哈希驗證和眾包策略這五個步驟，即使用戶緩存已經遭受污染，也能在后續的請求資源過程中檢測出污染資源并進行恢復。與傳統的緩存污染防御方案相比，本文提出的防御策略并不關注攻擊者通過何種手段污染用戶緩存，并且在變化的網絡環境中能夠進行自適應更新，使防御方案時刻保持著實用性與穩定性。

面對用戶行為的多樣性和防御策略環境的限制，接下來的工作需要對不同網絡環境和不同用戶群采用不同的防御策略，因為單一的標準往往不能適用于多種變化的環境和人群，設計不同的防御策略以便在今后工作中保證用戶安全性的同時仍然保持著良好的用戶體驗性。

參考文獻(References)

[1] 湯紅波,鄭林浩,葛國棟,等.CCN中基于節點狀態模型的緩存污染攻擊檢測算法[J].通信學報,2016,37(9):1-9.(TANG H B, ZHENG L H, GE G D, et al. Detection algorithm for cache pollution attacks based on node state model in content centric networking [J]. Journal on Communications, 2016, 37(9): 1-9.)

[2] 賈巖,王鶴,呂少卿,等.HTML5應用程序緩存中毒攻擊研究[J].通信學報,2016,37(10):149-157.(JIA Y, WANG H, LYU S Q, et al. Research on HTML5 application cache poison attack [J]. Journal on Communications, 2016, 37(10): 149-157.)

[3] LI M. Persistent JavaScript poisoning in Web browser’s cache [EB/OL]. (2015- 12- 12) [2017- 07- 14]. http://www.cs.tufts.edu/comp/116/archive/fall2015/mli.pdf.

[4] KLEIN A. Web cache poisoning attacks [M]// Encyclopedia of Cryptography and Security. Boston, MA: Springer, 2011: 1373-1373.

[5] HAY R, SHARABANI A. Protection against cache poisoning: U.S. Patent 8,806,133[P]. 2014- 08- 12.

[6] VALLENTIN M, BEN-DAVID Y. Quantifying persistent browser cache poisoning [EB/OL]. (2010- 04- 21) [2017- 07- 04]. http://matthias.vallentin.net/course-work/cs294-50-s10.pdf.

[7] VALLENTIN M, BEN-DAVID Y. Persistent browser cache poisoning [EB/OL]. [2017- 07- 20]. https://people.eecs.berkeley.edu/～yahel/papers/Browser-Cache-Poisoning.Song.Spring10.attack-project.pdf.

[8] JIA Y, CHEN Y, DONG X, et al. Man-in-the-browser-cache: persisting HTTPS attacks via browser cache poisoning [J]. Computers & Security, 2015, 55: 62-80.

[9] KUPPAN L. Attacking with HTML5 [EB/OL]. [2017- 04- 01]. https://www.techylib.com/en/view/victorious/attacking_with_html5.

[10] 方慧鵬,應凌云,蘇璞睿,等.移動智能終端的SSL實現安全性分析[J].計算機應用與軟件,2015,32(7):272-276.(FANG H P, YING L Y, SU P R, et al. Securiy analysis on SSL implementation of smart mobile terminals [J]. Computer Applications and Software, 2015, 32(7): 272-276.)

[11] JOHNS M, LEKIES S, STOCK B. Eradicating DNS rebinding with the extended same-origin policy [C]//SEC ’13: Proceedings of the 22nd USENIX Conference on Security. Berkeley, CA: USENIX Association, 2013: 621-636.

[12] SALTZMAN R, SHARABANI A. Active man in the middle attacks [EB/OL]. [2017- 03- 03]. http://www.security-science.com/pdf/active-man-in-the-middle.pdf.

[13] JIA Y, DONG X, LIANG Z, et al. I know where you’ve been: Geo-inference attacks via the browser cache [J]. IEEE Internet Computing, 2015, 19(1): 44-53.

[14] LEKIES S, JOHNS M. Lightweight integrity protection for Web storage-driven content caching [EB/OL]. [2017- 04- 11]. http://www.w2spconf.com/2012/papers/w2sp12-final8.pdf.

[15] KARAPANOS N, CAPKUN S. On the effective prevention of TLS man-in-the-middle attacks in Web applications [C]// Proceedings of the 23rd USENIX Conference on Security Symposium. Berkeley, CA: USENIX Association, 2014: 671-686.

[16] ALEXA.CN. Alexa [DB/OL] (2017) [2017- 08- 01]. http://www.alexa.cn/siterank/.

[17] 黎松,段海新,李星.域間路由中間人攻擊的實時檢測系統[J].清華大學學報(自然科學版),2015,55(11):1229-1234.(LI S, DUAN H X, LI X. Real-time system for detecting inter-domain routing man-in-the-middle attacks [J]. Journal of Tsinghua University (Science and Technology), 2015, 55(11): 1229-1234.)

[18] CLARK J, van OORSCHOT P C. SoK: SSL and HTTPS: Revisiting past challenges and evaluating certificate trust model enhancements [C]// Proceedings of 2013 IEEE Symposium on Security and Privacy. Washington, DC: IEEE Computer Society, 2013: 511-525.

[19] PRANDINI M, RAMILLI M, CERRONI W, et al. Splitting the HTTPS stream to attack secure Web connections [J]. IEEE Security and Privacy, 2010, 8(6): 80-84.

[20] 汪定,馬春光,翁臣,等.強健安全網絡中的中間人攻擊研究[J].計算機應用,2012,32(1):42-44.(WANG D, MA C G, WENG C, et al. Research of man-in-the-middle attack in robust security network [J]. Journal of Computer Applications, 2012, 32(1): 42-44.)

[21] NAYAK G N, SAMADDAR S G. Different flavours of man-in-the-middle attack, consequences and feasible solutions [C]// Proceedings of the 2010 3rd IEEE International Conference on Computer Science and Information Technology. Piscataway, NJ: IEEE, 2010, 5: 491-495.

This work is partially supported by the National Natural Science Foundation of China (61602258).

DAIChengrui, born in 1993，M.S. candidate. His research interests include network security, operating system security.

CHENWei, born in 1979, Ph. D., professor. His research interests include network security, privacy protection.