在剛結束的互聯網安全城市巡回賽中，R師傅憑借豐富的挖洞經驗，實現了8家SRC大滿貫，獲得了第一名的好成績！R師傅結合自身經驗並期許新手小白要多了解各種安全漏洞，並應用到實際操作中，從而豐富自己的挖洞經驗，積累挖洞技巧。（文末有R師傅的個人專訪，挖洞秘籍盡在其中）
今天i春秋就針對眾多安全漏洞中的SSRF進行詳細介紹，理論內容結合實際案例進行深度分析，幫助大家快速get新技能！本文閱讀用時約7分鍾。
什么是SSRF？
SSRF(Server-Side Request Forgery：服務器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF攻擊的目標是從外網無法訪問的內部系統。SSRF形成的原因大都是由於服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。
通俗的說，如果我們將換為與該服務器相連的內網服務器地址會產生什么效果呢？比如127.0.0.1、10.0.0.1、192.168.1.1等等，如果存在該內網地址就會返回1xx 2xx 之類的狀態碼，不存在就會返回其他的狀態碼；如果應用程序對用戶提供的URL和遠端服務器返回的信息沒有進行合適的驗證和過濾，就可能存在這種服務端請求偽造的缺陷。
到這里先解決兩個問題：
1、為什么要請求127.0.0.1、10.0.0.1、192.168.1.1，有什么區別呢？
答：127.0.0.1只是代表你的本機地址，如果該網站只有一個服務器的情況下，是可以訪問127.0.0.1的來判斷的，但要明確一點，127.0.0.1其實並不是內網地址，內網地址是有嚴格的地址段的，這是ipv4地址協議中預留的，分別是10.0.0.0--10.255.255.255、172.16.0.0--172.31.255.255 、192.168.0.0--192.168.255.255。
2、如果請求地址會返回狀態碼，那請求地址+端口會不會返回狀態碼呢？
答：當然會返回狀態碼，只是探測內網地址的話屬實不夠看的，所以如果一個點存在SSRF，那勢必要嘗試一下能不能探測內網端口，比如，假設10.0.0.1這個地址存在，那我們可以嘗試請求10.0.0.1:21、10.0.0.1:3306、10.0.0.1:6379等內網的常用端口，如果探測結果有收獲的話，那就可以為其他工作節省很多時間。
基礎的SSRF漏洞利用
隨便找了個輸入點，大家就假裝這個圖中的點就是漏洞點吧，因為真正的漏洞點不好放出來，也不好打碼，理解萬歲。
不過可能會有疑問，如何知道這個點就是漏洞點呢？其實這個東西不好回答，因為沒有成文的規定，經驗成分居多吧，如果看到讓用戶輸入url，導入外部鏈接的這些點，就可以去嘗試一下。
進入正題，如果這是一個漏洞點，那我們怎么應用？最簡單的方法，ceye.io。CEYE是一個用來檢測帶外流量的監控平台，如DNS查詢和HTTP請求。一些漏洞類型沒有直接表明攻擊是成功的，就如同此處的SSRF，Payload觸發了卻不在前端頁面顯示。這時候使用CEYE平台，通過使用諸如DNS和HTTP之類的帶外信道，便可以得到回顯信息。
用法也很簡單，登錄CEYE.IO，在用戶詳情頁可以看到自己的域名標識符 identifier，對於每個用戶，都有唯一的域名標識符abcdef.ceye.io 。所有來自於abcdef.ceye.io或.abcdef.ceye.io/ 的DNS查詢和HTTP請求都會被記錄。通過查看這些記錄信息，就可以判斷漏洞詳情。
比如我在此輸入我的域名標識符，如圖：
然后我就可以去ceye.io觀察是否有請求記錄，結果得到記錄：
當然我們也可以通過抓包，在包里修改url的信息構造不同的請求，然后觀察返回的狀態碼來探測信息。
所以通過上述兩種方法，就可以確定這個地方確實是有SSRF漏洞的。不過僅僅到這是不夠的，除非有進一步的操作證明危害，所以接下來會演示探測端口。
簡單的SSRF繞過
上面說的漏洞點本身就是一個讓用戶輸入鏈接的地方，那自然就不必繞過，但是如果漏洞點是一個加載圖片的地方，想必大家都見過社區或者論壇有這樣一個模塊點，就是可以讓用戶導入外部的圖片鏈接進行評論或者其他，比如下圖：
那么這種地方，也是可能存在SSRF的，不過當我們輸入ceye.io卻發現並沒有回顯請求，這是因為這種地方一般會對后綴做一個檢測，如果不是jpg或者其他圖片后綴的話並不會通過，不過好在ceye.io是很強大的，我們可以隨便構造，abcdef.ceye.io/ichunqiu.jpg, 對其進行輸入，再去觀察有無回顯，結果有了：
有其他限制的話都是一個道理，也可以在burp里截包改包達到此效果。
一個特殊的SSRF
有一次挖洞遇到一個站，就假設是www.xxx.com吧，是一個開源的系統，於是就在網上下載了這個開源的系統，一點一點的對其審計，在某個文件里發現這么一個鏈接：http://127.0.0.1/abc.php?url=http://www.baidu.com， 這可不是跳轉，結合上下代碼，發現此鏈接好像是服務器發起的請求操作，因為127.0.0.1是本機地址，所以嘗試構造http://www.xxx.com/abc.php?url=http://www.baidu.com， 發現也可以成功訪問，隱約覺得這是一個操作的地方，由於那個開源系統找不到了，所以沒法貼圖了，只能一步一步的詳細說了。
總之通過分析上下的代碼，發現這個鏈接的構成是由賦予abc.php一個外部的url參數，在沒有任何過濾，任何防護的情況下讀取這個外部url並發起請求，那么是否可以讀取內網地址呢？
於是構造：
http://www.xxx.com/abc.php?url=http://127.0.0.1:80， 為什么第一次就要訪問80端口？因為該站是可以訪問的，所以80端口必開放，第一次探測80也是想看一看正確返回與錯誤返回的區別，訪問完http://www.xxx.com/abc.php?url=http://127.0.0.1:80后， 得到正確的返回結果，就可以嘗試繼續訪問90端口，100端口，等等。
不過這個地方既然存在SSRF，且url參數沒有任何防護與過濾，那可不可以嘗試讀取文件呢？
繼續構造：
http://www.xxx.com/abc.php?url=file:///C:/Windows/win.ini
發現讀取成功，所以又成功探測到一枚文件讀取。
WebLogic的SSRF漏洞
我們接下來聊一下WebLogic的SSRF漏洞。WebLogic的SSRF漏洞算是一個比較知名的SSRF漏洞，具體原理可以自行谷歌。本篇主要是通過復現該漏洞來加深對SSRF漏洞的理解。
WebLogic的SSRF漏洞的存在頁面樣子是這樣的：
在學習這塊的時候，天真的以為只要存在這個頁面就必有SSRF，結果當然是否定的，在借鑒了豬豬俠大佬的PPT之后，發現一共有如圖四種回顯狀態：
那么可以通過構造：
http://xxx.com/uddiexplorer/SearchPublicRegistries.jsp?operator=http://
(要探測的內網地址)
&rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search
對其進行探測，觀察其回顯狀態，判斷是否存在目標網段，這個地方最主要的就是operator這個參數，主要思路就是通過修改這個參數，來探測內網地址和內網端口。不過問題來了，上面剛才說內網地址那么多，我們要怎么才能知道呢？
在WebLogicSSRF的漏洞頁面點擊這里：
就會來到這里，有時候由於配置不當的關系，這個地方會直接給出內網地址的網段：
有網段了，就可以一點一點的探測了，探測內網的telnet，ssh，redis，以及各個數據庫，為以后的內網漫游做好信息收集。還有，在WebLogic的SSRF中，有一個比較大的特點，就是雖然它是一個“GET”請求，但是我們可以通過傳入%0a%0d來注入換行符，而某些服務（如redis）是通過換行符來分隔每條命令，也就說我們可以通過該SSRF攻擊內網中的redis服務器。
手動反彈shell，就是常規的發送redis命令，然后把彈shell腳本寫入crontab中，最后用get發送命令，不過別忘了，get發送命令的時候要進行url編碼，最后在服務器上進行監聽就OK了。
當然，作為一名腳本小子，手動探測以及反彈shell太累了，在此貼上一個大牛的腳本，可以很方便的探測SSRF的網段以及每個網段的端口，甚至還有反彈shell的功能，地址：
https://github.com/NoneNotNull/SSRFX
總結
SSRF這個漏洞雖然在各大SRC上都被評為低危，但是這是因為它本身的危害有限，若是與其他漏洞結合起來會對你的滲透過程方便很多，它的強大之處是在於探測到一些信息之后從而進一步加以利用。比如獲取內網的開放端口信息，主機的信息收集和服務banner信息，攻擊內網和本地的應用程序及服務，還有就是利用file協議讀取本地文件等。
以上是今天的全部內容，大家看懂了嗎？
推薦閱讀