標籤：

SSRF（伺服器端請求偽造）漏洞

01-30
參考鏈接：bobao.360.cn/learning/d

典型漏洞：wooyun.org/bugs/wooyun-

wooyun.org/bugs/wooyun-

SSRF概述

SSRF(Server-Side Request Forgery:伺服器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF攻擊的目標是從外網無法訪問的內部系統。（正是因為它是由服務端發起的，所以它能夠請求到與它相連而與外網隔離的內部系統）

SSRF 形成的原因大都是由於服務端提供了從其他伺服器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定URL地址獲取網頁文本內容，載入指定地址的圖片，下載等等。

攻擊者利用ssrf可以實現的攻擊主要有5種：

1.可以對外網、伺服器所在內網、本地進行埠掃描，獲取一些服務的banner信息;

2.攻擊運行在內網或本地的應用程序（比如溢出）;

3.對內網web應用進行指紋識別，通過訪問默認文件實現;

4.攻擊內外網的web應用，主要是使用get參數就可以實現的攻擊（比如struts2，sqli等）;

5.利用file協議讀取本地文件等。

SSRF 漏洞的尋找

一、從WEB功能上尋找

我們從上面的概述可以看出，SSRF是由於服務端獲取其他伺服器的相關信息的功能中形成的，因此我們大可以列舉幾種在web 應用中常見的從服務端獲取其他伺服器信息的的功能。

1）分享：通過URL地址分享網頁內容

早期分享應用中，為了更好的提供用戶體驗，WEB應用在分享功能中，通常會獲取目標URL地址網頁內容中的<tilte></title>標籤或者<meta name="description" content=「」/>標籤中content的文本內容作為顯示以提供更好的用戶體驗。例如人人網分享功能中：

1

widget.renren.com/*****?resourceUrl=https://www.sobug.com

通過目標URL地址獲取了title標籤和相關文本內容。而如果在此功能中沒有對目標地址的範圍做過濾與限制則就存在著SSRF漏洞。

根尋這個功能，我們可以發現許多互聯網公司都有著這樣的功能，下面是我從百度分享集成的截圖如下：

從國內某漏洞提交平台上提交的SSRF漏洞，可以發現包括淘寶、百度、新浪等國內知名公司都曾被發現過分享功能上存在SSRF的漏洞問題。

2）轉碼服務：通過URL地址把原地址的網頁內容調優使其適合手機屏幕瀏覽

由於手機屏幕大小的關係，直接瀏覽網頁內容的時候會造成許多不便，因此有些公司提供了轉碼功能，把網頁內容通過相關手段轉為適合手機屏幕瀏覽的樣式。例如百度、騰訊、搜狗等公司都有提供在線轉碼服務。

3）在線翻譯：通過URL地址翻譯對應文本的內容。提供此功能的國內公司有百度、有道等

4）圖片載入與下載：通過URL地址載入或下載圖片

圖片載入遠程圖片地址此功能用到的地方很多，但大多都是比較隱秘，比如在有些公司中的載入自家圖片伺服器上的圖片用於展示。（此處可能會有人有疑問，為什麼載入圖片伺服器上的圖片也會有問題，直接使用img標籤不就好了？ ，沒錯是這樣，但是開發者為了有更好的用戶體驗通常對圖片做些微小調整例如加水印、壓縮等，所以就可能造成SSRF問題）。

5）圖片、文章收藏功能

此處的圖片、文章收藏中的文章收藏就類似於功能一、分享功能中獲取URL地址中title以及文本的內容作為顯示，目的還是為了更好的用戶體驗，而圖片收藏就類似於功能四、圖片載入。

6）未公開的api實現以及其他調用URL的功能

此處類似的功能有360提供的網站評分，以及有些網站通過api獲取遠程地址xml文件來載入內容。

在這些功能中除了翻譯和轉碼服務為公共服務，其他功能均有可能在企業應用開發過程中遇到。

二、從URL關鍵字中尋找

在對功能上存在SSRF漏洞中URL地址特徵的觀察，通過我一段時間的收集，大致有以下關鍵字:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

share

wap

url

link

src

source

target

u

3g

display

sourceURl

imageURL

domain

...

如果利用google 語法加上這些關鍵字去尋找SSRF漏洞，耐心的驗證，現在還是可以找到存在的SSRF漏洞。

SSRF 漏洞的驗證

1）基本判斷（排除法）

例如：

1

douban.com/***/service?image=baidu.com/img/bd_logo1.

排除法一：

你可以直接右鍵圖片，在新窗口打開圖片，如果是瀏覽器上URL地址欄是baidu.com/img/bd_logo1.，說明不存在SSRF漏洞。

排除法二：

你可以使用burpsuite等抓包工具來判斷是否不是SSRF，首先SSRF是由服務端發起的請求，因此在載入圖片的時候，是由服務端發起的，所以在我們本地瀏覽器的請求中就不應該存在圖片的請求，在此例子中，如果刷新當前頁面，有如下請求，則可判斷不是SSRF。（前提設置burpsuite截斷圖片的請求，默認是放行的）

此處說明下，為什麼這邊用排除法來判斷是否存在SSRF，舉個例子：

1

http://read.*******.com/image?imageUrl=baidu.com/img/bd_logo1.

現在大多數修復SSRF的方法基本都是區分內外網來做限制（暫不考慮利用此問題來發起請求，攻擊其他網站，從而隱藏攻擊者IP，防止此問題就要做請求的地址的白名單了），如果我們請求 ：

1

read.******.com/image?imageUrl=10.10.10.1/favicon.ico

而沒有內容顯示，我們是判斷這個點不存在SSRF漏洞，還是10.10.10.1/favicon.ico這個地址被過濾了，還是10.10.10.1/favicon.ico這個地址的圖片文件不存在，如果我們事先不知道10.10.10.1/favicon.ico這個地址的文件是否存在的時候是判斷不出來是哪個原因的，所以我們採用排除法。

2）實例驗證

經過簡單的排除驗證之後，我們就要驗證看看此URL是否可以來請求對應的內網地址。在此例子中，首先我們要獲取內網存在HTTP服務且存在favicon.ico文件的地址，才能驗證是否是SSRF漏洞。

找存在HTTP服務的內網地址：

一、從漏洞平台中的歷史漏洞尋找泄漏的存在web應用內網地址

二、通過二級域名暴力猜解工具模糊猜測內網地址

1

example:ping xx.xx.com.cn

可以推測10.215.x.x 此段就有很大的可能： 10.215.x.x/favicon.ico 存在。

在舉一個特殊的例子來說明：

1

fanyi.baidu.com/transpa

此處得到的IP 不是我所在地址使用的IP，因此可以判斷此處是由伺服器發起的baidu.com/s? 請求得到的地址，自然是內部邏輯中發起請求的伺服器的外網地址（為什麼這麼說呢，因為發起的請求的不一定是fanyi.baidu.com，而是內部其他伺服器）,那麼此處是不是SSRF，能形成危害嗎？ 嚴格來說此處是SSRF，但是百度已經做過了過濾處理，因此形成不了探測內網的危害。

SSRF 漏洞中URL地址過濾的繞過

1）baidu.com@10.10.10.10與10.10.10.10 請求是相同的

此腳本訪問請求得到的內容都是baidu.com的內容。

2）ip地址轉換成進位來訪問

1

115.239.210.26 ＝ 16373751032

此腳本解析的地址都是 115.239.210.26，也可以使用ping 獲取解析地址：

如果WEB服務簡單的過濾參數中獲取的URL地址，沒有判斷真正訪問的地址，是有可能被此兩種方法繞過的。

文中"SSRF 漏洞中URL地址過濾的繞過"小節參考：URL Hacking - 前端猥瑣流[0x_Jin] drops.wooyun.org/tips/7

本文轉載自 sobug

原文鏈接：https://sobug.com/article/detail/11


推薦閱讀：

TAG:信息安全 |