讀取型CSRF-須要交互的內容劫持

本文做者：i春秋做家——jing0102

前言

最近在挖洞，"實踐出真知"這句話說的很對，在實際挖掘過程當中我會思考不少東西，跟朋友一塊兒準備作一份手冊，突然的想到了一些漏洞的定義和規範。在大多數的人眼裏CSRF可能僅僅是寫入型的好比：修改我的資料、受權登錄等等功能場景的CSRF問題，同時對CSRF這類問題進行了危害等級劃分，就像如上兩個例子，能夠劃分爲中危和高危。也許是由於交互式的漏洞並無SQLi這種直接能利用的漏洞危害高，因此一些廠商對CSRF也並不重視。

步入正題，什麼是讀取型CSRF，這裏我對以下的漏洞概括進了讀取型CSRF，由於這些漏洞的利用手法都跟CSRF是同樣的：

• JSON劫持
• Flash跨域劫持
• CORS跨域資源讀取

…等等，固然還有Silverlight跨域這些了，不過這裏只列舉常見的三種來說解。

讀取型CSRF

接下以如上所說的三個漏洞案例來一個個分析。

JSON劫持

漏洞案例

這裏來看一條請求：

這條請求返回的結果中有手機號（這裏我測試的帳號沒綁定手機），若是咱們想要以CSRF交互式攻擊的方式獲取這個手機號該怎麼辦？

來看看這條請求有callback，而返回結果是否是相似Javascript中的函數？

Javascript原函數定義以下：

function funName(){}

這裏是缺乏了函數定義的關鍵詞function和花括號的函數主體部分，只有函數名和函數傳參，聰明人已經想到了，這不就至關因而自定義函數被引用了麼，而中間那段傳參就至關因而一個數組，因此咱們能夠先用JS自定義好這個函數，而後再引用這個請求，天然就能夠獲取到數據了。

這時候咱們能夠來構建一下PoC：

<!-- 引用一段如上請求爲JS -->
<script>function jsonp2(data){alert(JSON.stringify(data));}</script> <script src="http://gh0st.cn/user/center?callback=jsonp2"></script>

使用正常的帳號(綁定過手機號)來測試下：

案例總結

其實經過這個例子，咱們能夠知道HTML標籤<script>在必定的狀況下是能夠跨域讀取的。

對此漏洞的修復有不少：

1.打亂響應主體內容

2.Referer等進行限制

…..等等

Flash跨域劫持

Flash跨域比較經典了，在作web目錄資產整理的時候有時候會發現這樣的文件 crossdomain.xml ，文件內容若是是以下的，那麼就存在Flash跨域問題，以下內容的意思是支持全部域：

<?xml version="1.0"?>
<cross-domain-policy>   <allow-access-from domain="*" /> </cross-domain-policy>

爲何會如此？具體流程是這樣的：

gh0st.cn 有一個SWF文件，這個文件是想要獲取 vulkey.cn 的 userinfo 的返回響應主體，SWF首先會看在 vulkey.cn 的服務器目錄下有沒有 crossdomain.xml 文件，若是沒有就會訪問不成功，若是有 crossdomain.xml ，則會看crossdomain.xml 文件的內容裏面是否設置了容許 gh0st.cn 域訪問，若是設置容許了，那麼 gh0st.cn 的SWF文件就能夠成功獲取到內容。因此要使Flash能夠跨域傳輸數據，其關鍵就是crossdomain.xml 文件。

當你發現 crossdomain.xml 文件的內容爲我如上所示的內容，那麼就是存在Flash跨域劫持的。

漏洞案例

在對一個廠商進行測試的時候正好發現了這樣的文件：

在這裏我須要作兩件事：

1.找到一個能獲取敏感信息的接口

2.構建PoC

在這裏敏感的信息接口以我的中心爲例子，PoC使用的是 https://github.com/nccgroup/CrossS彩色文字iteContentHijacking/raw/master/ContentHijacking/objects/ContentHijacking.swf

案例總結

很簡單的一個東西，可是用處卻很大，其利用方法跟CSRF也是同樣的，只須要修改下PoC就行。

修復方案一樣也很簡單，針對<allow-access-from domain="*" />的domain進行調整便可。

CORS跨域資源讀取

漏洞案例

如上圖中我在請求的時候加上了請求頭 Origin: http://gh0st.cn，而對應的響應包中出現了Access-Control-Allow-Origin: http://gh0st.cn這個響應頭其實就是訪問控制容許，在這裏是容許http://gh0st.cn的請求的，因此http://gh0st.cn是能夠跨域讀取此網址的內容的~在這裏我介紹下Origin：

Origin和Referrer很類似，就是將當前的請求參數刪除，僅剩下三元組（協議 主機 端口），標準的瀏覽器，會在每次請求中都帶上Origin，至少在跨域操做時確定攜帶（例如ajax的操做）。

其實要測試是否能夠跨域讀取能夠參考我如上的方法，固然不只如此，你能夠直接使用通配符()替換個人域名，由於這表明着任意域，若是對應的響應包中出現了`Access-Control-Allow-Origin: `等響應頭，那麼恭喜你，這裏存在着任意域跨域資源讀取的問題。

怎麼利用呢？在這裏我使用了github上的開源項目:https://github.com/nccgroup/CrossSiteContentHijacking，readme.md中有具體的說明，這裏我就不一一講解了，那麼已經確認問題了，那就須要進一步的驗證。

在這裏我找到了一處接口，其響應主體內容是獲取用戶的真實姓名、身份證、手機號等內容：

/daren/author/query （要注意的是這個請求在抓取的時候是POST請求方式，但並無請求正文，通過測試請求正文爲任意內容便可）

響應報文正文內容：

這裏CrossSiteContentHijacking項目我搭建在了本地(127.0.0.1) http://127.0.0.1/CrossSiteContentHijacking/ContentHijackingLoader.html

根據項目所說的操做去進行參數的配置，而後點擊 Retrieve Contents 按鈕：

測試以下，測試結果是能夠跨域讀取的：

案例總結

這個問題其實就是對Origin的驗證沒有控制好，對其進行增強便可。

結尾

結尾想說的東西其實也沒什麼了，總結了這些東西但願能幫助到各位~

>>>>>>  黑客入門必備技能  帶你入坑和逗比表哥們一塊兒聊聊黑客的事兒，他們說高精尖的技術比農藥都好玩~