使用Fuzzing自動檢測Web應用程式中的漏洞(半機翻有刪增)

摘要： 自動檢測漏洞是文獻中研究的問題，也是具有安全要求的應用程式開發中非常重要的問題。Fuzzing是一種軟體測試技術，自動或半自動化，涉及在軟體中注入大量半隨機輸入以解決安全漏洞。許多漏洞檢測技術需要專業人員進行手動分析，以確定是否存在任何漏洞。為了解決這個問題，決定開發一個使用模糊測試自動檢測W...

自動檢測漏洞是文獻中研究的問題，也是具有安全要求的應用程式開發中非常重要的問題。Fuzzing是一種軟體測試技術，自動或半自動化，涉及在軟體中注入大量半隨機輸入以解決安全漏洞。許多漏洞檢測技術需要專業人員進行手動分析，以確定是否存在任何漏洞。為了解決這個問題，決定開發一個使用模糊測試自動檢測Web應用程式漏洞的系統。檢測Web應用程式中的漏洞與在其他型別的軟體中檢測不同。發生這種情況是因為Web應用程式包含許多後端元件，這會導致特定的漏洞，因此，它可以方便地監視這些元件。這項工作提供了一個模糊Web應用程式的框架。在這項工作中，在每個Web應用程式元件內部進行監視。該框架檢測一組有代表性的Web應用程式漏洞：SQL注入、本地或者遠端檔案包含、反射型或者儲存型XSS。我們的SQL注入檢測機制能夠檢測最近提出的這一類別的細微攻擊。我們使用易受攻擊的程式碼示例和開源Web應用程式對框架進行實驗性評估。

介紹

漏洞檢測是文獻中廣泛研究的主題，也是具有安全性要求的軟體開發中的一個非常重要的問題。通過模糊測試發現了許多軟體漏洞。Fuzzing 是一種軟體測試技術， 涉及在軟體中重複注入半隨機輸入，以便由目標應用程式處理，並檢查是否存在與預期不同的行為 。如果是這樣，某個輸入可能會利用錯誤或漏洞。

此外，模糊測試是一種半自動或自動化過程，其中包括髮送更有可能利用漏洞的值。 有兩類模糊器：基於突變和基於生成 。基於變異的模糊器通過在輸入中應用微小變化而不改變其結構來建立測試用例。基於生成的模糊器通過目標知識建立測試用例。

許多Web應用程式都具有複雜的體系結構，這是一個挑戰，也是檢測某些注入是否利用漏洞的機會。在非Web應用程式（如網路服務或命令列）中，模糊器僅嘗試傳送輸入，但使用者必須瞭解目標軟體中是否存在任何異常行為。其他機制試圖通過觀察崩潰，監視CPU時間或記憶體消耗來檢測異常行為。但是，使用者需要了解這些異常是否是軟體中的漏洞。許多Web應用程式漏洞與後端元件相關，例如，資料庫管理系統（DBMS）或檔案系統，這使監視變得複雜，但也允許在這些點上執行此操作。

本文提出了一個框架，用於模糊Web應用程式，以滿足這一挑戰和機遇。該工作的主要重點是監控目標應用中的注入效應，因此主要在其元件內部進行。

該框架旨在檢測輸入驗證漏洞，但在當前版本中，只實現了它們的一部分：SQL注入（SQLI）;本地/遠端包含（LFI / RFI）;反射/儲存的跨站點指令碼（XSS）。選擇這個漏洞子集是因為SQL和XSS幾年來被認為是風險最高的漏洞，而LFI / RFI對用PHP編寫的Web應用程式有特殊影響。

PHP語言目前在超過77％的Web應用程式中使用，這就是我們考慮它的原因。這項工作還展示瞭如何擴充套件框架以檢測其他輸入驗證漏洞。

該框架被實現為由Zend Engine執行的PHP應用程式中的漏洞並使用MySQL作為DBMS。它通過小型易受攻擊的程式碼示例和開源應用程式進行評估，同時考慮到發現的漏洞數量。

背景

檢測漏洞利用

要確定是否漏洞已被利用，必須存在可以檢測目標系統狀態的監視機制或資源，尤其是在出現故障的情況下，例如：可記錄任何故障或執行異常的日誌檔案;允許識別系統中的異常的偵錯程式;應用程式返回的程式碼或訊息;檢查與目標系統的連線是否仍然存在。但是，此類機制尚未整合到模糊器中，因為無法準確檢測利用Web應用程式中的漏洞的攻擊。

web 應用漏洞

本節簡要介紹了當前版本框架中考慮的漏洞。 對於每種型別的漏洞，都存在具有相同名稱的相應攻擊，例如，SQL注入攻擊/漏洞。

SQL注入漏洞

允許攻擊者使用輸入來誤導目標應用程式，以構建意外查詢並將其提交到資料庫。當用戶的輸入未經過驗證並且攻擊者可能通過插入SQL關鍵字來更改查詢的結構時，就會發生此類攻擊。如果此類攻擊對目標的行為有立即影響，則稱為一階SQL注入。在二階SQLI攻擊中，攻擊者首先向目標應用程式提供一個輸入，它將儲存在資料庫中;之後，攻擊者提供第二個輸入，該輸入建立查詢以提取儲存的最後一個查詢，然後建立第二個修改查詢。

RFI漏洞

允許攻擊者從外部Web伺服器中包含檔案。此漏洞的發生是由於缺少使用者輸入的驗證，允許攻擊者通過包含函式包含遠端內容，例如PHP中的函式包含。

LFI漏洞

與之前類似，但包含的檔案必須存在於應用程式伺服器中。為了執行此類攻擊，首先，必須載入惡意檔案或在現有本地檔案中新增惡意內容（例如：日誌檔案）。在那之後，它只需要包含這個惡意的本地檔案。

反射型XSS漏洞

當Web應用程式信任來自使用者的輸入並在響應中回顯它們而沒有經過驗證、清理或編碼時就會存在反射型XSS漏洞。 如果這些輸入中的任何一個包含指令碼，它將在受害者的瀏覽器中執行，並帶來一些後果。

儲存型XSS漏洞

基於先前漏洞的相同原則，僅在這種情況下，目標應用程式首先儲存資料並隨後回顯它。

檢測特定的Web應用程式漏洞

在本小節中將討論以下漏洞的幾種檢測技術：SQL注入，本地/遠端檔案包含和跨站點指令碼。

有許多方法可以檢測SQLI漏洞。

Halfond和Orso的解決方案， 通過靜態程式碼分析 檢測這種型別的攻擊，並在 執行時監視應用程式 。此外，還有一種解決方案CANDID基於SQL注入更改查詢結構的原則。在此解決方案中 ，通過傳送良性輸入，作者打算提取所需的查詢模型，以便與從未來請求生成的模型進行比較 。如果模型之間沒有匹配，則表示存在SQLI漏洞。這種方法不同於本工作中實現的SQLI檢測機制，因為CANDID需要更改目標應用程式，而且，提取查詢結構是DBMS的一個外部工具，可能無法提取查詢結構。

關於檢測RFI漏洞的機制

他們假裝檢查在到達關鍵功能（例如包括）之前 是否存在不安全的輸入是否是任何驗證，消毒或編碼過程的目標 。如果是，則輸入變得安全，否則可能利用漏洞。 中

還有一種解決方案發送一個輸入，該輸入引用被監視的遠端伺服器中的資源，以確定它是否已從目標應用程式接收到任何請求。如果是這樣，Web應用程式容易受到攻擊，因為它試圖包含目標遠端檔案。

檢測LFI漏洞

為了檢測LFI漏洞，提出了一種解決方案，其中作者建議在目標應用程式中包含可執行資源，並確定應用程式行為是否有任何變化。

要檢測XSS漏洞，有幾種機制

一種機制基於靜態分析。這些機制控制程式的執行， 在作為響應傳送之前，檢查使用者的輸入是否是任何驗證或清理過程的目標 。除了這種方法之外，還有一種方案 使用代理來分析對應用程式及其響應的請求 。此解決方案檢查請求中是否存在與HTML標記對應的任何字元。如果是，則該機制檢查相應的響應是否包含相同的現有標記，以檢查目標應用程式中是否存在任何漏洞。

其實就是一種是檢查請求是否有異常，另一種是鍵查響應是否有異常

框架

它開發了一個框架，用於模糊測試Web應用程式並通過嵌入在後端元件中的機制監視它們的影響。接下來，將介紹框架的體系結構及其元件。

體系結構

Framework的體系結構如下圖所示，其中包含其元件：

Fuzzer：

生成在目標Web應用程式的某些入口點注入的輸入。此外，它還包含反映XSS攻擊的監視機制。

Web應用程式：

顧名思義，它是由框架測試的Web應用程式。 它插入到具有特定作業系統的Web伺服器中，並與許多後端元件（例如資料庫，檔案系統）通訊;

伺服器端語言直譯器：

其中包括由於缺少輸入驗證而導致的漏洞的幾種檢測機制。如果它們分別與檔案系統，DBMS或作業系統互動，則這些漏洞分為三類。

(1)監視執行的位置

監視以下漏洞：本地/遠端檔案包含（LFI / RFI）;目錄/路徑遍歷（DT / PT）;原始碼洩露（SCD）。

(2)檢測儲存的XSS攻擊的機制。

(3)OS命令包含攻擊（OSCI）的監視機制。

(4)還有一種伺服器端語言程式碼注入攻擊的監視機制。

資料庫管理系統：

從Web應用程式接收查詢並對其進行處理。它包含SQL注入攻擊的監視機制。

特性

接下來，將展示開發框架的每個元件中存在的所有功能。

Fuzzer

fuzzer 基於通過模糊向量生成輸入，將自身插入迭代 fuzzer 的類別中。這些模糊測試向量包含一組先前選擇的輸入，包含幾個存在的攻擊特徵。此外，fuzzer 對 這些向量的每個元素應用突變機制。 該機制隨機地選擇輸入字元的子集以進行小的改變（例如：字元替換），從而產生可能意外地利用漏洞的更多種輸入。

fuzzer 允許在傳送輸入之前將目標應用程式置於特定狀態，將其自身插入記憶體模糊器的類別中。因此，可以手動地定義一系列請求以將目標應用程式置於給定狀態或在傳送特定輸入後重置目標應用程式的狀態。這一系列請求包含以下型別的HTTP請求：GET和POST。

此外，fuzzer 負責通過HTTP協議將生成的輸入注入目標應用程式。為此，模糊向量的每個元素的 fuzzer 傳送其原始版本和它們的突變 。如果啟用了狀態定義機制，則首先，fuzzer傳送與預狀態程序相對應的HTTP請求，即將目標應用程式置於某個狀態以便對其進行測試。置於特定狀態，fuzzer 將輸入傳送到目標應用程式。稍後，如果需要重置目標應用程式的狀態，則 fuzzer 傳送HTTP請求以重新建立其狀態。重複執行此過程，直到所有輸入都發送到目標應用程式。

檢測SQL注入

在DBMS中檢測到這種型別的漏洞，因為該機制使用其資源，更具體地說是其解析器。在下面的解釋中，我們考慮了MySQL的具體情況，因為它是實現中使用的DBMS。

SQLI攻擊檢測的主要目標是識別某個查詢是否接收來自使用者的輸入，如果其結構發生變化則考慮到良性模型結構。因此，首先，有必要 確定目標應用程式中每個查詢的預期行為 。此標識的 目的是能夠比較某個查詢的不同執行並檢查其行為是否發生變化 。如果是這樣，應用程式中存在漏洞。

在MySQL的特定情況下，查詢的結構可以被解釋為堆疊或後序樹。但是，MySQL將查詢的結構儲存在列表中。

接下來，通過SQLI檢測機制呈現下面查詢語句的結構。

SELECT * FROM user WHERE Age<23

為了理解查詢的結構，必須從下到上觀察其專案。

查詢結構中的第一個元素是指FROM元素，在本例中是表使用者。之後，它引用SELECT子句返回的元素，在本例中為所有collumns（符號*）。接下來，有一個對年齡和整數23的引用，並且應用這兩個專案<操作，如上面的專案所示。

在此解決方案中，假設輸入是良性的，首先執行接收輸入的某個查詢，定義查詢的模板。因此，當第一次執行查詢時，在執行時，機制將儲存其結構。將在以下相同查詢的執行中將此模板與獲得的結構進行比較。

為了正確的操作機制，必須存在訓練階段，對其中執行程式碼中的所有點執行從具有良性內容的使用者接收輸入的查詢以便生成模板。

在以下查詢的執行中，將獲得的結構與在訓練階段生成的相應模板進行比較。這種比較必須能夠容忍某些方面，否則會產生許多誤報。

例如，假裝將給定屬性與使用者指定的值進行比較的查詢必須容忍所提供的不同值。此外，它應該容忍使用與預期不同的值，但由於型別轉換操作，這些值的含義是相同的。因此，該機制在稱為基本型別的類別中考慮整數，浮點數，實數和字串型別。

因此，該檢測機制從獲得的結構中觀察每個元素，並檢查型別（第一元素）和引數（剩餘元素）是否與模板中的對應元素完全相等，除了在一種情況下。當查詢結構的某些元素引用基本型別時，不必分析其引數，只需要模板中的對應元素為基本型別。

如果給定查詢獲得的結構與相應模板不對應，則意味著輸入已更改查詢的結構，並且它正在利用SQLI漏洞

該機制可以檢測兩種型別的SQL注入攻擊：結構和模仿。此外，此機制能夠檢測一階和二階SQLI漏洞， 因為在這兩種情況下，當漏洞被利用時，查詢結構會發生變化 。

出於安全目的，在模板中，不儲存原始型別的引數，因此不可能提取任何敏感資訊（例如密碼）。

為了演示這種機制，我們假設以下查詢：

SELECT info FROM users WHERE password = $input。

此查詢執行兩次：第一次為了生成帶有良性輸入’xpto’的模板;第二個為了用惡意輸入攻擊’evil’ or 1 = 1。下圖顯示的結構，分別表示為兩個執行的堆疊，

（a）模板
（b）惡意查詢的結構（以粗體輸入）

可以觀察到結構之間的差異，因為它在查詢中包含惡意SQL程式碼作為輸入，因此，該機制可以識別出SQLI漏洞。

檢測本地/遠端檔案包含

要檢測LFI / RFI攻擊，必須在每個檔案包含函式呼叫中提取有關包含檔案的資訊，例如，在PHP語言函式include和require中。這種檢測是在伺服器端語言直譯器內進行的

當第一次執行某個檔案包含函式時，假設使用良性輸入，機制定義該呼叫的預期行為，以便與該位置的未來的執行情況進行比較，將其定義為模板。此模板通用於涵蓋所有良性輸入，但也限制為排除惡意輸入。存在訓練階段是必要的，其中存在這種型別的函式的程式碼中的所有位置都用良性輸入執行以便生成相應的模板。

模板包含檔案的路徑和副檔名。如果檔案是遠端的，則路徑包括外部地址的協議（例如：http：//）

選擇這些元素作為模板的一部分的原因基於兩個原則：當攻擊者假裝包含本地或遠端檔案時，檔案的路徑必須通過路徑遍歷或包括外部地址協議來改變，而在正常執行中路徑保持不變;當有一個檔案包含時，它的擴充套件在執行時是相同的，因此認為改變檔案的擴充套件是一個危險的操作。

在以下執行中，檢測機制將特定呼叫中包括的檔案與相應模板進行比較。 如果包含檔案的路徑或副檔名與模板中定義的路徑或副檔名不同，則表示目標應用程式中存在漏洞。

接下來，該機制檢查是否包含檔案。如果是這樣，該機制會漏洞利用漏洞，否則會警告漏洞會被利用。

只有當攻擊者試圖在模板中包含具有相同路徑和副檔名的惡意檔案時，則出現此機制的限制

檢測儲存型 XSS

為了檢測儲存型XSS攻擊， 每當執行查詢時，該機制都會檢查按查詢返回的內容是否包含Web瀏覽器可以解釋的任何程式碼 。此檢測在伺服器端語言直譯器中進行，內容分析通過解析工具進行，該工具檢查其中是否有任何程式碼。解析工具分析查詢返回的內容，並檢查是否有任何HTML或JavaScript程式碼標記（例如 <script> ）

在通過解析工具分析內容之前，該機制會對此進行預檢查，因為查詢返回的大多數內容都是無害的，從而導致效能開銷。此預檢查假裝驗證是否存在任何危險字元（例如：<，>）或字串（例如：href，javascript）。如果是這樣，查詢返回的內容是解析工具分析的目標，否則是無害的，沒有必要進行任何進一步的分析。

如前所述，在預檢查階段之後，解析工具分析查詢返回的內容並檢查是否存在可由Web瀏覽器解釋的任何程式碼標記。 如果是這樣，則檢測機制通知儲存的跨站點指令碼攻擊。

檢測反射型 XSS

此機制檢測是否傳送指令碼作為Web應用程式的響應。此檢測在 fuzzer 內部進行。在 fuzzer 嚮應用程式傳送輸入之前，需要在考慮存在的情況下分析這些輸入 程式碼（例如：HTML，JavaScript）。 如果是，則機制通過輸入向目標應用程式傳送HTTP請求。 接下來，分析應用程式的響應。

該分析通過Smith-Waterman演算法檢查響應是否具有重要的輸入部分。該演算法用於計算生物學領域，在兩個字元序列之間進行區域性對齊，並通過評分系統工作。在該得分系統中，當兩個字元之間存在匹配時新增點，否則扣除點。這些分數可能因目標字元而異，例 如，字元<和>的分數高於其他字元，因為它在此漏洞中具有重要性。 該演算法返回具有最高相似性的字元子序列，即其得分是最高的。在檢測機制的目的中，它執行輸入和應用程式響應之間的區域性對齊，以獲得與輸入具有更高相似性的響應子序列。 如果獲得的分數是完美的 ，即獲得的子序列與輸入完全對應的，我們可以得出結論， 目標應用程式是易受攻擊的 。 如果獲得的分數不完美但高於閾值，則機制檢查從演算法獲得的子序列 。該分析想要檢查子序列中是否有任何程式碼。如果是這樣，那麼它就是一個漏洞，否則被視為應用程式顯著改變了輸入。

作為限制，機制可能無法識別某些輸入中的程式碼，因此無法識別漏洞，或者與輸入相比，響應中的響應發生了顯著變化，但仍然觸發了攻擊。

在正常執行中，將作為輸入插入字串Miguel，其未標識任何程式碼，因此不傳送輸入。假設將惡意內容

<script> alert（“XSS”）</script>

作為輸入插入，這被標識為程式碼，因為有指令碼標記，因此傳送輸入。當收到響應時，會對此進行分析，並確定輸入中的現有程式碼完全包含在響應中，即通知存在反射型 XSS 漏洞

為了證明這種機制，請考慮以下程式碼示例，它接收來自使用者的輸入，並在後面反射它，它是這樣的：

$name = $ GET[ ' name ' ] ;
echo "Welcome " . $name ;

檢測其他漏洞

如前所述並在圖1中提到，可以擴充套件框架以檢測Web應用程式中存在的其他漏洞，例如，OS命令注入漏洞（OSCI），伺服器端語言程式碼注入，目錄/路徑遍歷和原始碼洩露

框架旨在分析與這些漏洞相關的敏感接收器，並檢查是否存在任何漏洞利用。為此，需要修改與每個漏洞相關的後端元件，並收集有關應用程式從使用者發出的請求的資訊。

該資訊集中在請求結構中，以便根據使用者的輸入檢查結構是否存在任何差異。在第一階段， 有必要收集每個呼叫與這些漏洞相關的函式的良性模型。接下來，當執行特定呼叫時，將獲得的結構與各自的良性模型進行比較。如果存在差異，則機制通常存在漏洞， 因為請求的結構與從良性輸入獲得的結構不同

實現

本節介紹了框架的架構，並考慮了實現的元件(如下圖)，此外，它還解釋了框架的元件是如何實現的，即以下漏洞的模糊和檢測機制：SQL注入，本地/遠端檔案包含和反射/儲存XSS。

Fuzzer

為了實現fuzzer，它使用了由OWASP開發的名為JBroFuzz（版本2.4）的工具,該工具包含一個fuzzer以及一個包含多個類的庫，這些類允許實現包含各種功能的fuzzer：模糊向量或模糊測試有多個引數。由於JBroFuzz fuzzer 不包含監視攻擊的機制，因此必須使用此庫來建立具有檢測 XSS攻擊機制的fuzzer。

還有必要實現其他功能：輸入變異機制;使用生成的輸入傳送HTTP請求。關於模糊向量，fuzzer 模糊器包含針對每個漏洞的攻擊簽名，這些漏洞假裝從不同的源和複雜性中檢測到

Web應用程式經歷了幾個狀態，其中只有一些是易受攻擊的。 因此，當使用模糊測試來檢測目標應用程式中的漏洞時，重要的是在所有不同的狀態下進行並在每個狀態下進行模糊測試。 fuzzer的當前實現包含一種機制，允許手動定義一組HTTP請求以將目標應用程式置於特定狀態或在傳送輸入後重置應用程式的狀態。 可以提供請求的型別，URL，引數和cookie。

檢測 SQLI

要實現這個機制，有必要修改MySQL（版本5.7.4。），更具體地說，解析函式（mysql parse - le sql parser.cc）新增14行程式碼。此外，它建立了一個帶有1098行程式碼的標題檔案，以實現檢測機制。通過這些更改，可以檢測到多個SQLI攻擊。

要實現這種機制，有必要修改MySQL（版本5.7.4。），更具體地說，解析函式（mysql parse-sql parser.cc）新增14行程式碼。 此外，它建立了一個帶有1098行程式碼的標題檔案，以實現檢測機制。 通過這些更改，可以檢測到多個SQLI攻擊。

此外，有必要以MySQL註釋的形式向每個查詢新增識別符號。發生這種情況是因為這些識別符號可以在應用程式中知道執行某些查詢的位置。因此，程式設計師能夠通過程式碼分析瞭解某些漏洞的原因。如果在查詢中沒有這樣的識別符號，MySQL繼續正常執行只是不是機制的目標。

當前實現僅允許分析包含以下命令的查詢：SELECT，INSERT INTO，UPDATE，FROM，WHERE，HAVING，ORDER BY，GROUP BY。

檢測本地/遠端檔案包含

為了實現這個機制，有必要修改PHP直譯器（版本5.5.12），即Zend Engine。 這些更改集中在直譯器的函式中，這些函式在PHP語言中實現檔案包含函式 （例如：include，include once，require和require once）。 由此可以提取與包含目標相關的資訊，並檢查目標應用程式是否易受攻擊 。

需要更改名為compile_file（zend_language_scanner.c）的ZendEngine函式。此函式接收將由PHP編譯的檔案作為引數，在本例中為包含的目標。

有必要在每個包含函式呼叫中新增一個識別符號，以便知道程式碼中哪個位置確定包含。如果沒有這樣的識別符號，PHP繼續正常執行只是不是檢測機制的目標。

為了提取有關包含函式識別符號的資訊，它被修改為file_zend_vm_execute.h，共有116行程式碼。通過更改此功能，檢測機制能夠區分漏洞警告和攻擊真正利用漏洞的時間。

關於模板，它們通過包含相關資訊的檔案永久儲存。

檢測儲存型 XSS

為了實現這個機制，它被修改了Zend Engine（版本5.5.12）。這些修改主要集中在實現PHP函式mysql查詢的直譯器函式，更具體地說，函式php mysql在Zend Engine中執行查詢。

要分析查詢返回的內容，有必要檢查其中是否有任何程式碼，例如HTML或JavaScript。因此，它使用了一個用Java編寫的解析工具（antixss.jar），它包含一個解析庫，即jsoup（版本1.7.3），該庫旨在解析HTML頁面或其他類似語言（例如JavaScript，CSS）考慮到標籤的存在。為了識別程式碼，機制為jsoup分析提供內容。此解析工具將內容插入到虛擬HTML頁面中，由標記 <html> <head> <body> 表示，其中將進行解析。

利用通過解析過程獲得的結構，將檢查除了虛擬頁面中的現有標籤之外是否還存在至少一個程式碼標籤。如果是這樣，則意味著內容已更改結構幷包含程式碼。

檢測反射型 XSS

為了實現這個機制，它再次被用於jsoup庫（版本1.7.3），但在這種情況下包含在fuzzer中（圖3）。

關於Smith-Waterman演算法，它是用Java語言實現的。有必要使用某些值來確定機制，以便在字元之間達成一致/不一致，間隙和所得到的得分與完美得分之間的相似性百分比被視為某種輸入作為攻擊。

如果兩個角色之間存在協議（區分大小寫），則會增加5分。當角色之間存在分歧時，這可以是三種類型：

• 當對於包括對齊的子序列的空白空間的不一致關注從得分中扣除2個單位。這個懲罰是線性的，取決於新增的空格數量;
• 當分歧指的是彼此不同 但不是字元 的兩個字元< 或 >從分數中扣除5個單位。根據不同意見中的字元數，這種懲罰是線性的;
• 當分歧指的是兩個不同的字元時，其中一個字元<或>被扣除25倍於前一點扣除的單位。這是因為這些角色在反射型XSS 漏洞中的重要性，這種懲罰是線性的，取決於分歧中的字元數。

最後，當使用Smith-Waterman演算法獲得的分數大於完美分數的95％時，確定某些輸入利用反映的XSS漏洞，即，如果對比較兩個序列之間的所有字元，則獲得分數。

結論

這項工作提供了一個框架，用於模糊Web應用程式並通過監視機制檢測漏洞。所開發的解決方案與現有技術中提出的解決方案不同，因為在這項工作中，監視機制嵌入在Web應用程式的後端元件中。

這種型別的監控方法有許多優點：作為執行流的最後元素，不需要對以前的實體做出假設;不依賴於任何清理，驗證或編碼過程;使用來自Web應用程式元件的資源以幫助檢測。

當前的框架版本可以檢測到多個漏洞：SQL注入，本地/遠端檔案包含以及反射/儲存的跨站指令碼。

此外，該框架能夠將目標應用程式置於特定狀態，以便在所有狀態下進行測試。

此外，SQL注入檢測機制在考慮Ray和Ligatti程式碼注入定義的情況下進行了測試。我們可以得出結論，開發機制比其他最先進的機制表現更好。

關於未來的工作，我們考慮開發剩餘的漏洞檢測機制：OS命令注入;伺服器端語言程式碼注入;目錄/路徑遍歷;原始碼披露。此外，可以通過狀態識別功能來自動地分析目標應用程式並推斷其執行狀態，從而改進 fuzzer。

個人總結

本文介紹了常見的漏洞檢測技巧

sqli : 靜態程式碼分析和動態執行監控(動靜結合)，模型檢測法

L/RFL : 包含遠端檔案或者是可執行檔案，觀察遠端伺服器或者本地伺服器的變化

XSS : 一種是檢查請求是否有異常，另一種是鍵查響應是否有異常

並開發了一個自動化的框架去實現這些檢測