10分鐘走進安全/滲透測試：用最簡單的話聊一聊(XSS)跨站指令碼攻擊

跨站指令碼攻擊(XSS)是一種將惡意指令碼注入到可信任網站中的一種攻擊方式。在XSS攻擊中，攻擊者利用web應用程式將惡意程式碼傳送至終端使用者。這些惡意指令碼通常經由瀏覽器端形式呈現， 惡意攻擊者往web頁面裡插入惡意Script程式碼，當使用者瀏覽該頁面時，嵌入web頁面中的Script程式碼就會被執行，這樣即可達到惡意攻擊使用者的目的。

【概述】

在網際網路中，XSS幾乎到處可見，例如：當應用程式接受使用者輸入時，這些內容在未經驗證或編碼的情況下，就直接經由web應用程式生成相應的輸出。XSS漏洞藉助於php輸出函式，將javascript程式碼輸出到html頁面中，再透過使用者本地瀏覽器執行，所以在程式碼稽核中，查詢XSS漏洞的關鍵就在於找到那些入參未經過濾的輸出函式。

攻擊者利用XSS將惡意指令碼傳送給毫無戒心的大眾使用者，瀏覽器端使用者們在不知情的情況下執行了這些不受信任的惡意指令碼，從而洩漏了自己在瀏覽器端保留個人隱私身份驗證等相關狀態資訊(如：與該站點相關的cookie、session、token以及其他敏感資訊)。此外，攻擊者的惡意指令碼甚至還可以重寫HTML頁面內容。

【XSS分類】

反射型XSS：

攻擊者事先製作好惡意連結，需要使用者自己去點選連結才能觸發XSS程式碼(這些程式碼不會被儲存至服務端)。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

儲存型XSS：

惡意程式碼儲存在伺服器中,如攻擊者在個人資訊或發表文章等頁面中加入惡意指令碼;在接受輸入引數時，如果沒有對這些入參進行過濾或過濾不嚴謹，那麼頁面中的惡意程式碼將儲存到伺服器中，一旦有使用者訪問該頁面時，就會觸發惡意程式碼。這種XSS非常危險，容易造成蠕蟲(會大量盜竊使用者cookie資訊)。

【反射型XSS詳解】

當攻擊者在單個HTTP響應中注入瀏覽器可執行的程式碼，這時就會發生反射型跨站指令碼攻擊(Reflected_XSS)。由於這類注入攻擊不會駐留在應用程式本身，所以它是一種非永續性注入，僅對於那些開啟惡意連結(刻意製作的)或第三方頁面的使用者造成影響。這些帶有攻擊性的惡意字串包含在攻擊者精心設計的URL或HTTP引數中，被存在安全隱患的應用程式處理後，將結果返回給使用者(受害者/被攻擊者)。

反射型跨站指令碼攻擊(Reflected_XSS)是XSS攻擊中最常見的型別，這類攻擊也稱非持久型XSS攻擊，因為此類攻擊的載體源於單個請求，透過響應將返回結果傳遞給客戶端瀏覽器，然後被使用者執行，從而觸發Reflected_XSS(Reflected_XSS也稱一階XSS，即XSS的第一種型別)。

一個易受到Reflected_XSS攻擊的web應用程式，會將請求中未經驗證的輸入透過響應直接回傳給客戶端。常見的攻擊手段/途徑有：精心設計步驟(攻擊者建立問題URI)，社會工程相關(試圖說服受害者將其URL載入到他們的瀏覽器上)，最終攻擊者就能透過受害者的瀏覽器來執行問題程式碼。

從前文可知，攻擊者的程式碼大多都用JavaScript語言編寫，當然也可以是其他指令碼語言，例如ActionScript，VBScript等。攻擊者通常利用web應用程式漏洞來安裝金鑰日誌，竊取受害者的Cookie，進行剪貼簿盜竊，以及更改頁面內容(例如新增下載連結等)。

預防XSS漏洞的主要困難之一是如何設定合適的字元編碼進行引數過濾。在某些情況下，Web伺服器或Web應用程式可能無法過濾一些特殊的字元編碼，例如Web應用程式可能會過濾掉<script>，但也許不會過濾 ”%3cscript%3e“。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

【反射型XSS測試方法】

(1)黑盒測試

黑盒測試包含三個階段：

檢測輸入

針對web應用程式中每個頁面上的使用者自定義輸入，測試人員必須確定其輸入形式，包括隱藏(hidden)，或者非顯式的輸入，如：HTTP引數、POST資料、表單中的隱藏欄位以及預定義的單選(radio)或下拉選框(selection)中的值。 這些隱藏變數可以透過瀏覽器內建HTML編輯器或是web代理來檢視。

分析輸入

分析頁面上每一項使用者輸入以檢測潛在漏洞。為了發現XSS漏洞，測試人員通常會將“定製化”資料作為輸入框的測試資料，這類測試資料不會對應用程式造成損害，其目的只是用於觸發來自瀏覽器的響應，從而驗證漏洞是否存在。測試資料可以透過[web application fuzzer]自動生成或手動構造，例如：

更多有關潛在測試字串的完整列表，參見。

檢查影響

對於以上所有測試資料，測試人員需要關注並分析其提交後的響應結果，從而確定每條資料是否對web應用程式安全性造成實際影響(漏洞的存在)。一旦發現漏洞，測試人員需要識別出漏洞存在的原因，例如：應用程式未對輸入資料採取合適編碼，應用程式對某些特殊字元沒有進行過濾或替換等。

理想情況下，所有HTML的特殊字元都要替換成HTML實體：

更多HTML實體規則可以參見：

在HTML或JavaScript程式碼上下文中，特殊字元需要轉義，編碼，替換或過濾，這些字元包括：

更多完整參考，請參見[Mozilla JavaScript指南]：

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Grammar_and_types#Using_special_characters_in_strings

Example 1

有如下站點自帶welcome提示及下載連結：

測試人員本著懷疑每個資料輸入點都可能導致XSS攻擊的原則，對其進行分析後，嘗試以下測試資料：

如果出現如下彈出框，則說明存在一個XSS漏洞，並且這個連結可以在任何瀏覽器中執行。

Example 2

除了在URL中提交植入的 JS alert彈框外，還可以有如下嘗試：

從URL附帶的提交資料中可以發現，測試人員(模仿攻擊者)改變了當前頁面中的超連結資源，將連結引導到一個惡意的可執行檔案，只要這個超連結被使用者點選，就會在本地自動下載惡意檔案“malicious.exe”：

值得一提的Bypass XSS Filters

當web應用程式啟用防火牆阻止惡意輸入，或透過web瀏覽器中自帶的內嵌機制，清理應用程式的外來輸入時，反射型跨站指令碼攻擊(Reflected_XSS)是可以防止的。

但在測試的時候，測試人員必須假定web瀏覽器是不具備阻止攻擊的機制，且客戶端也未開啟防火牆，這是因為在一些過時的瀏覽器中，相關過濾機制內建的安全防範功能已經被禁用了。同樣的道理，我們也不能保證即便客戶端防火牆開啟後，web應用程式能夠識別“與時俱進”的未知攻擊，網路攻擊者往往緊跟時代步伐，製作出web應用程式防火牆無法識別的攻擊性字串。

大多數XSS預防取決於Web應用程式對“不可信使用者”輸入的清理。開發人員可以透過多種機對“問題輸入”進行淨化，例如返回錯誤，刪除，編碼或替換無效輸入。

Example 3：Bypass XSS Filters —— 僅透過標籤屬性值

雖然Bypass XSS Filters基於黑名單，但並不能阻止每種型別的字串表示式。在實際情況下，甚至於不需要依賴<script>標籤就能發起XSS攻擊。例如頁面中有如下input輸入框：

攻擊者可以直接在該輸入框中提交以下程式碼：

" >

Example 4：Bypass XSS Filters —— 透過編碼植入未知變體

在某些情況下，可以透過混淆攻擊來簡單地破壞基於簽名的過濾器。通常，攻擊者可以透過在語法或後續編碼中插入未知變體(如下例項)來實現此目的。當返回時，瀏覽器會將這些變體視為有效的HTML內容。

Example 5：Bypass XSS Filters —— 繞過非遞迴機制的過濾

有時過濾器的清理僅應用一次，不會遞迴執行。在這種情況下，攻擊者可以透過傳送包含多次嘗試的字串來擊敗多濾器，例如：

Example 6：Bypass XSS Filters —— 包含外部指令碼

假設目標站點的開發人員實現了以下程式碼，用來保護輸入內容免受外部指令碼的影響。

以上程式碼中的正規表示式： $re = "/<script>+src/i"

用來檢查是否存在這樣的插入：<script [anything but the character: '>'] src

這種判斷僅針對於過濾類似於如下常見攻擊有效。

但可以在script和src中間的某個屬性利用”>“字元進行繞過， 從而發起reflected-XSS攻擊，不知不覺中讓使用者執行了攻擊者web伺服器上儲存的javascript程式碼，例如：

可以看出這裡利用了reflected-XSS漏洞，執行了javascript程式碼，這些程式碼看似來自受害網站， 實際上是儲存在攻擊者的Web伺服器上。

(2)灰盒測試

這裡的灰盒測試有點類似黑盒測試，但需要測試人員對應用程式有一定的瞭解，例如使用者可能的輸入，輸入的驗證機制，輸入提交後的返回資訊，以及返回資訊呈現給使用者的方式。如果測試人員有許可權可以檢視原始碼(白盒測試)，那麼還需要對每個使用者變數進行深入分析，此處已涉及更多白盒測試相關領域，暫不進行擴充。

【總結】

文章介紹了Cross Site Scripting (XSS) 跨站指令碼及其分類展開介紹，其中針對反射型XSS(reflected-XSS)漏洞以及常見測試方法，應用場景進行詳細剖析，對於軟體測試從業者而言，無論是否身兼安全/滲透測試一職，都需對基本的安全漏洞有宏觀的認知，希望本次分享能夠給各位帶來收穫，持續完善你的測試知識庫。