前言

虛擬補丁（VP）近年來一直是保護應用程序最受歡迎的方法之一，如果在Web應用程序防火墻層級添加VP功能，該功能可用于保護Web應用程序免遭已知漏洞的威脅攻擊。簡而言之，VP利用靜態(tài)應用程序安全測試（SAST）的結果并使用它們來創(chuàng)建規(guī)則以用來過濾WAF上的HTTP請求。 但問題在于，SAST和WAF依賴于不同的應用程序模型和不同的決策方法。因此，目前可用的解決方案中沒有一個能夠將SAST與WAF完美的結合起來。SAST基于白盒模型，它采用公式方法來檢測代碼中的漏洞。然而，WAF將應用程序視為黑盒子，因此它使用啟發(fā)式方式進行攻擊檢測。但是如果我們能讓SAST和WAF完美的結合在一起使用，我們可以通過SAST獲取有關應用程序內部結構的信息，并將這些信息提供給WAF，這樣我們就可以以一種“優(yōu)雅”的方式來檢測網(wǎng)絡攻擊。

傳統(tǒng)VP

一般地，在Web應用程序傳統(tǒng)自動化虛擬修補方法中，我們需要向WAF提供SAST檢測到的每個漏洞信息，這些信息包括：

漏洞分類

Web應用程序的脆弱點

攻擊所需的HTTP請求參數(shù)值

構成攻擊向量脆弱點參數(shù)的值

脆弱點參數(shù)中可用于漏洞利用的一組字符或一個單詞。

一般地，我們可以通過定義某些函數(shù)來獲取HTTP請求中的參數(shù)值，例如下面是一段易受XSS攻擊的ASP.NET頁面的代碼片段：

通過分析針對上面頁面的攻擊向量代碼，我們可以生成一組攻擊向量值的符號公式：

{condition =“secret”⇒param∈{XSShtml-text}} ，其中XSShtml-text是TEXT上下文中用于XSS攻擊的向量集合。在實際的應用場景中，WAF虛擬補丁的描述符可用于生成過濾規(guī)則，以阻止所有能夠利用相關漏洞的HTTP請求。

雖然這種做法肯定會導致某些攻擊，但它有一些很大的缺點：

為了表示任何給定的漏洞，SAST需要發(fā)現(xiàn)一個可能的攻擊向量。 但為了確保能夠真正消除一個漏洞，SAST有必要處理所有可能的攻擊向量。但是SAST很難將這些信息傳遞給WAF，因為由于攻擊向量語法的不規(guī)則性，矢量集不僅是無窮大的，甚至不能用正則表達式來表達。

對于漏洞利用所需的其他請求參數(shù)的值也是如此。

如果入侵點和脆弱執(zhí)行點之間的攻擊向量語法在其上下文中發(fā)生了變化，那么有關脆弱參數(shù)的信息將變得沒有任何的價值。

由于這些設計上的缺陷，對于SAST檢測到的漏洞，VP技術不能針對其提供可能的攻擊保護。嘗試創(chuàng)建這種“全面的”流量過濾規(guī)則通常會阻止合法HTTP請求并中斷Web應用程序的操作，下面讓我們稍微修改漏洞的代碼：

與上一個例子的區(qū)別是：在對兩個請求參數(shù)都做了Decode處理，針對該新代碼的攻擊向量公式如下所示：

靜態(tài)分析會在相關計算流程圖（ConfiG）節(jié)點中為自定義解碼函數(shù)導出一個公式，以描述Base64-URL-Base64轉換鏈，如下所示：

針對這樣的公式，我們仍然有可能在其基礎上構建一個漏洞，但是由于以下原因，生成虛擬補丁的方法不能應用于此：

只有當請求中的“condition”參數(shù)包含“secret”子字符串時，才可能利用此漏洞。 然而，該參數(shù)的值集是非常大的，并且由于解碼功能的不規(guī)則性，通過正則表達式表達該集合是不可行的。

事實上，攻擊向量的請求參數(shù)也被解碼。因此，SAST無法將該組危險元素描述為WAF。

由于傳統(tǒng)VP的所有問題都源于無法與基于白盒方法的WAF級別的應用程序進行交互，因此明顯的解決方案是實現(xiàn)此功能并進一步改進，以便：

SAST向WAF提供有關易受攻擊的參數(shù)以及從進入點到易受攻擊的執(zhí)行點這整個過程中對攻擊變量所做的所有轉換信息。

對于攻擊檢測，啟發(fā)式方法被公式方法所替換，并且包含任何漏洞的利用條件信息。

因此，運行時虛擬補丁應運而生。

運行時虛擬補丁

運行時虛擬修補（RVP）的原理是基于PT應用檢查器（PT AI）中的計算流程圖模型實現(xiàn)的。與公式符號計算的語義表示類似，該模型是使用應用程序代碼的抽象解釋構建出來的，模型中的圖節(jié)點包含了目標語言的生成公式，并且公式產(chǎn)生與相關執(zhí)行點上的所有數(shù)據(jù)流相關聯(lián)的所有合法值的集合，具體如下圖所示：

上圖中的這些流被稱為執(zhí)行點參數(shù)。 由于CompFG是可評估的，因此我們可��根據(jù)輸入?yún)��?shù)的值，在任何執(zhí)行點上計算所有參數(shù)的值。 通常情況下，RVP分為部署（D）和運行（R）兩個階段，這倆個階段分別對應于應用程序生命周期，具體如下圖所示：

部署階段

在部署新版本的應用程序之前，應用程序由PT AI分析，并且為那些易受攻擊的執(zhí)行點中的每個CompFG節(jié)點計算三個公式：

獲取脆弱執(zhí)行點的條件

獲取其所有參數(shù)值的條件

所有參數(shù)及其相應語法的值集

上述中的所有公式集都將按照應用程序的入口點進行分組，入口點定義于分析器的數(shù)據(jù)庫中，并和PT AI支持的每個Web框架相關聯(lián)。通過提取包含的漏洞信息以及從代碼（基于S-expression語法的特殊語言編寫的代碼，編程語言使用不依賴于目標語言的形式來描述CompFG公式）中提取相關的公式列表形成一份報告，例如上述代碼示例中描述脆弱點參數(shù)值的公式如下：

獲取脆弱點的公式是：

然后將報告被上傳到PT應用防火墻 （PT AF），在報告的基礎上，PT WAF生成二進制模塊，該模塊可以計算報表中包含的所有公式。 例如，用于計算達到上述脆弱點的條件的反編譯代碼如下：

為了對公式進行計算操作，PT AF必須具有以下條件之一：

預先計算可能在報告中出現(xiàn)的所有函數(shù)

具有沙箱運行環(huán)境，用于運行Web應用程序或其他平臺（如CLR，JVM或PHP，Python或Ruby解釋器）以及應用程序中使用的庫

第一種方法在一定程度上能夠保證速度很快，但WAF開發(fā)人員需要大量的手動工作來描述預計算數(shù)據(jù)庫，即使開發(fā)人員將范圍限制為標準庫函數(shù)。第二種方法允許計算報告中可能出現(xiàn)的所有函數(shù)，但這種方法會增加處理每個HTTP請求所需的時間，因為WAF需要訪問運行時環(huán)境來對每個函數(shù)執(zhí)行計算操作。這里最合適的解決方案是使用第一種方法進行最常見函數(shù)的計算，而對其余函數(shù)使用第二種方法。

公式中很可能會包含分析器無法處理的函數(shù)或者PT AF無法計算的函數(shù)，這些函數(shù)在公式中會被標記為“unknown”，并以如下所述的特殊方式進行處理。

運行階段

在運行階段，WAF將每個HTTP請求的處理委托給二進制模塊，該模塊分析請求并檢測Web應用程序中的相關入口點。為此，WAF會選擇所有檢測到的漏洞公式，然后以特定方式執(zhí)行計算操作。

首先，計算公式的兩個條件為：1）到達脆弱點，2）獲取其所有參數(shù)的值。 在每個公式中，變量用相關請求參數(shù)的值代替，之后計算公式值。 如果公式包含標記為“unknown”的表達式，則其處理如下：

每個“unknown”標志通過公式表達式樹自下而上擴展，直到找到布爾表達式。

在公式中，這樣的表達式會被布爾變量替換，以用來解決布爾可滿足性問題。

假設通過上一步驟生成了關于“unknown”的n個公式，那么計算每個公式的值。 如果至少有一個公式是可滿足的，那么該假設也被認為是可以滿足的。

如果計算顯示假設為假，那么即使所有請求參數(shù)都有危險的值，HTTP請求也無法將應用程序引導到易受攻擊的點。在這種情況下，RVP只需向WAF的核心模塊返回請求處理即可。如果攻擊條件滿足，那么WAF會計算脆弱點的參數(shù)值，使用的算法取決于分析點所屬的漏洞等級。這些算法之間的相似之處是用于處理包含未知節(jié)點公式的邏輯：與假設公式不同，在計算時參數(shù)公式不會被計算，而是立即被傳達給WAF。為了更好地理解這一點，我們現(xiàn)在將回顧一下用于檢測注入攻擊的最復雜的算法。

檢測注入攻擊

注入攻擊通過將特定形成的輸入數(shù)據(jù)傳遞給應用程序來執(zhí)行惡意操作，當這些數(shù)據(jù)被“注入”到目標文本中（包括HTML, XML, JavaScript, SQL, URLs, 以及文件路徑）時，文本中包含了應用程序邏輯不想要的句法結構。如果一個脆弱點屬于這個攻擊類，那么它的參數(shù)值是可以通過使用污點分析語義中抽象解釋的增量計算來確定的。這種方法背后的思想是：從下到上分別計算每個表達式，同時獲得每個步驟的計算結果、每個函數(shù)的語義以及傳統(tǒng)污點檢查的規(guī)則。例如，對于上述代碼和以下HTTP請求參數(shù)：

將此算法應用于弱點參數(shù)的公式的結果如下（污染參數(shù)標記為紅色）：

然后根據(jù)脆弱點參數(shù)的語法對該值進行標記，如果任何污點的片段匹配多個令牌，那么就代表這是一次注入的攻擊。

一旦與當前入口點相關的所有漏洞的公式計算結束，請求處理將與檢測結果一起傳遞給WAF的核心模塊。

RVP優(yōu)點和具體功能

與傳統(tǒng)VP相比，這種基于代碼分析的應用程序保護方法具有很大的優(yōu)勢：

得益于上述公式方法以及所有中間轉換的能力，傳統(tǒng)VP的缺點得到了解決。

公式方法也完全排除了假陽性的可能性，只要公式不包含未知節(jié)點

對Web應用程序功能沒有不利影響，因為保護是建立在應用程序的功能上，而不是簡單地試圖解決它們。

為了測試該技術并確認其有效性，我們開發(fā)了一種用于PT應用程序檢查器和PT應用程序防火墻的模塊原型，實驗結果表明大約十五個開源內容管理系統(tǒng)（CMS）的性能測試顯示出很好的結果：使用RVP處理HTTP請求所需的時間與使用傳統(tǒng)（啟發(fā)式）WAF方法處理此類請求所需的時間相當。 Web應用程序的平均性能如下：

對于那些非攻擊的請求占比為0％

對于那些非攻擊請求，但會導致脆弱點的占比為6-10％

對于那些是攻擊請求的，且會導致脆弱點的占比為4-7％

盡管與傳統(tǒng)VP相比有明顯優(yōu)勢，但RVP仍有幾個概念上的缺點：

不可能在WAF（包括文件資源，數(shù)據(jù)庫和服務器環(huán)境）上計算包含來自外部源的數(shù)據(jù)公式。

公式的質量直接取決于分析期間代碼片段的質量（包括循環(huán)，遞歸和對外部庫方法的調用）。

為了描述預計算數(shù)據(jù)庫中函數(shù)的語義，需要開發(fā)人員加入到其中，該描述過程很難自動化，且容易出現(xiàn)人為錯誤。

然而，我們已經(jīng)設法通過將一些RVP功能從應用程序中刪除并使用RASP技術來緩解上述這些缺陷。

本文由 安全客 翻譯，轉載請注明“轉自安全客”，并附上鏈接。

本文鏈接：http://m.51huadong.com/cloundnews/11001451.html