SSRF——服務端請求偽造，上一篇，我談到了CSRF客戶端請求偽造，這個是我們通過攻擊用戶，引誘客戶點擊我們偽造好的表單，從而達到我們攻擊的目的，是從客戶端發起的，那么SSRF服務端請求偽造當然是通過我們的目標網站也就是我們的服務端而發起我們滲透攻擊的目的。

再說一下，平常在做滲透測試工作的過程中哪些地方容易產生SSRF漏洞，可以看到大部分相關資料都會顯示，容易產生SSRF的地方在社交分享、圖片加載、郵件系統、數據庫等。為什么這些地方會出現呢，社交分享可能會分享到其他網址對吧，如果我們替換其網址為我們的本地地址呢，會出現什么樣得情況？同一個地址更換不同的端口又會有什么不同，加載圖片請求的服務器可能和你所訪問的網站不是同一個服務器，這樣是不是能探測內網的同一局域網段的情況呢，郵件系統也是同一道理，這些都是探測SSRF漏洞的手段。

所以本質上就是因為你向其他地方請求的資源和你本身的網站資源不在同一個地方，因此，平常在做滲透測試過程中，只要參數帶有URL的或者IP地址的就都有可能會產生SSRF漏洞，檢查方法：改端口，探測哪些端口開啟，換網址，局域網內不同的主機是否開啟。這就和盲注的情況一樣，存在和不存在會出現不同的情況。

接下來就讓我們來看下Weblogic服務的SSRF漏洞是怎么體現的，通過這樣的漏洞我們能獲的什么樣的信息。

本次復現的SSRF漏洞是Weblogic應用服務，版本號是10.3.6，漏洞編號為CVE-2014-4210，為了更好的讓人理解，我將本次漏洞的展示與說明寫的簡潔明了，安裝跳過，漏洞出現的頁面位于 http://IP:7001/uddiexplorer/SearchPublicRegistries.jsp，這個是屬于weblogic的一個組件，是不需要登錄就能直接訪問的網頁，我們看下這個漏洞傳輸的數據包的展示，選擇第一個Search PublicRegistries選項，我這里任意輸入一個值text，點擊Search按鈕發送數據包。

這里我們知道請求并不是向某一網址發起請求，而是向本地發送一個test的表單數據，但這里我們可以看到表單數據其中的一個參數operator，它有一個網址值域名為http://www-3.ibm.com，這里是weblogic請求自帶的一個參數，而這里就是產生SSRF漏洞的所在，和我們自己輸入的參數值text卻沒有關系，我們只是為了發送這樣一個請求才添加個test值。

為什么說在這里會產生SSRF漏洞呢，因為在這里我們通過變更這個URL的參數，根據響應包返回的數據獲得服務器內部的相關信息。

這里我們既然開啟了weblogic服務，那么，在沒改默認端口的情況下，服務器的7001端口必然開啟，為了方便，我直接將7001端口用來測試展示，發起請求，抓包將我們的operator參數后面的網址改為http://127.0.0.1:7001傳給服務器，這里是要加上http協議的，此時我們可以看到頁面響應的內容報出異常提示返回404錯誤碼。

我知道我自己的服務器上7002端口是關閉沒有服務的，這里將我的operator參數更換為http://127.0.0.1:7002來發包，這個時候我們可以看到網頁上面的內容顯示和端口為7001的不一樣，現在報的異常是不能鏈接本地7002端口，而不是7001這樣的返回404錯誤碼。

也就是說，服務端口開啟與未開啟會給你返回兩種不同的網頁狀態，通過這種不同的情況，我們能夠探測該weblogic所在服務器哪些危險端口開啟和未開啟，這就和盲注判斷數據的性質一樣，通過這種朝向服務端自己的請求讓我們能夠了解內網信息的漏洞，我們將它歸類為SSRF漏洞。

本次漏洞復現資源，微信公眾號：滲透之師，回復005，另外附贈wooyun大佬-豬豬俠的ssrf滲透框架的ppt內容哦！下期內容XXE，敬請期待！