????????SSRF(Server-Side Request Forgery:服務器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF攻擊的目標是從外網無法訪問的內部系統。（正是因為它是由服務端發起的，所以它能夠請求到與它相連而與外網隔離的內部系統）
????????SSRF 形成的原因大都是由于服務端提供了從其他服務器應用獲取數據的功能且沒有對目標地址做過濾與限制。比如從指定URL地址獲取網頁文本內容，加載指定地址的圖片，下載等等。
SSRF 漏洞的尋找
一、從WEB功能上尋找
????????我們從上面的概述可以看出，SSRF是由于服務端獲取其他服務器的相關信息的功能中形成的，因此我們大可以列舉幾種在web 應用中常見的從服務端獲取其他服務器信息的的功能。
1）分享：通過URL地址分享網頁內容
????????早期分享應用中，為了更好的提供用戶體驗，WEB應用在分享功能中，通常會獲取目標URL地址網頁內容中的<tilte></title>標簽或者<meta name="description" content=“”/>標簽中content的文本內容作為顯示以提供更好的用戶體驗。例如人人網分享功能中：
http://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地址特征的觀察，通過我一段時間的收集，大致有以下關鍵字:
share
wap
url
link
src
source
target
u
3g
display
sourceURl
imageURL
domain
...
如果利用google 語法加上這些關鍵字去尋找SSRF漏洞，耐心的驗證，現在還是可以找到存在的SSRF漏洞。
SSRF 漏洞的驗證
1）基本判斷（排除法）
例如：
http://www.douban.com/***/service?image=http://www.baidu.com/img/bd_logo1.png
排除法一：
????????你可以直接右鍵圖片，在新窗口打開圖片，如果是瀏覽器上URL地址欄是http://www.baidu.com/img/bd_logo1.png，說明不存在SSRF漏洞。
排除法二：
????????你可以使用burpsuite等抓包工具來判斷是否不是SSRF，首先SSRF是由服務端發起的請求，因此在加載圖片的時候，是由服務端發起的，所以在我們本地瀏覽器的請求中就不應該存在圖片的請求，在此例子中，如果刷新當前頁面，有如下請求，則可判斷不是SSRF。（前提設置burpsuite截斷圖片的請求，默認是放行的）
此處說明下，為什么這邊用排除法來判斷是否存在SSRF，舉個例子：
http://read.*******.com/image?imageUrl=http://www.baidu.com/img/bd_logo1.png
????????現在大多數修復SSRF的方法基本都是區分內外網來做限制（暫不考慮利用此問題來發起請求，攻擊其他網站，從而隱藏攻擊者IP，防止此問題就要做請求的地址的白名單了），如果我們請求 ：
http://read.******.com/image?imageUrl=http://10.10.10.1/favicon.ico
????????而沒有內容顯示，我們是判斷這個點不存在SSRF漏洞，還是http://10.10.10.1/favicon.ico這個地址被過濾了，還是http://10.10.10.1/favicon.ico這個地址的圖片文件不存在，如果我們事先不知道http://10.10.10.1/favicon.ico這個地址的文件是否存在的時候是判斷不出來是哪個原因的，所以我們采用排除法。
2）實例驗證
????????經過簡單的排除驗證之后，我們就要驗證看看此URL是否可以來請求對應的內網地址。在此例子中，首先我們要獲取內網存在HTTP服務且存在favicon.ico文件的地址，才能驗證是否是SSRF漏洞。
找存在HTTP服務的內網地址：
一、從漏洞平臺中的歷史漏洞尋找泄漏的存在web應用內網地址
二、通過二級域名暴力猜解工具模糊猜測內網地址
example:ping xx.xx.com.cn
可以推測10.215.x.x 此段就有很大的可能： http://10.215.x.x/favicon.ico 存在。
????????在舉一個特殊的例子來說明：
http://fanyi.baidu.com/transpage?query=http://www.baidu.com/s?wd=ip&source=url&ie=utf8&from=auto&to=zh&render=1
????????
????????此處得到的IP 不是我所在地址使用的IP，因此可以判斷此處是由服務器發起的http://www.baidu.com/s?wd=ip 請求得到的地址，自然是內部邏輯中發起請求的服務器的外網地址（為什么這么說呢，因為發起的請求的不一定是fanyi.baidu.com，而是內部其他服務器）,那么此處是不是SSRF，能形成危害嗎？ 嚴格來說此處是SSRF，但是百度已經做過了過濾處理，因此形成不了探測內網的危害。
SSRF 漏洞中URL地址過濾的繞過
1）http://www.baidu.com@10.10.10.10與http://10.10.10.10 請求是相同的
此腳本訪問請求得到的內容都是www.baidu.com的內容。
2）ip地址轉換成進制來訪問
115.239.210.26 ＝ 16373751032
????????此腳本解析的地址都是 115.239.210.26，也可以使用ping 獲取解析地址：
????????如果WEB服務簡單的過濾參數中獲取的URL地址，沒有判斷真正訪問的地址，是有可能被此兩種方法繞過的。
