SSRF服務端請求偽造（外網訪問內網）

SSRF(Server-Side Request Forgery:服務器端請求偽造) 是一種由攻擊者構造形成由服務端發起請求的一個安全漏洞。一般情況下，SSRF是要目標網站的內部系統。（因為他是從內部系統訪問的，所有可以通過它攻擊外網無法訪問的內部系統，也就是把目標網站當中間人）

其實也就相當于一個中間人攻擊（主要目的就是：由外網攻擊者利用SSRF漏洞攻擊內網）

一般來說基本都是通過腳本去掃內網的ip、端口點到為止

1、SSRF形成原因

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

即也就是說服務器端的驗證并沒有對其請求如獲取圖片的參數（image=）做出嚴格的過濾以及限制，從而導致A網站可以從其他服務器的獲取數據

 

（默認網站webserver192.168.1.5的參數指定訪問內網中的某臺機器的內部資源地址，如果沒有對其指定地址嚴格限制，那么就可能造成由webserver192.168.1.5這太機器訪問內部的任意一臺機器的資源。）——>>如：www.xxx.com/xx.php?image=URL，一般像分享、在線翻譯這些功能地址。

即我們要對目標網站的架構了解，腦子了要有一個架構圖。比如 ： A網站，是一個所有人都可以訪問的外網網站，B網站是一個他們內部的OA網站，我們普通用戶只可以訪問a網站，不能訪問b網站。但是我們可以同過a網站做中間人，訪問b網站，從而達到攻擊b網站需求。

主要標志就是：xx.php?url=.....

(也可以命令執行，需要條件。甚至腳本執行。。。。)

2、利用SSRF漏洞的目的

SSRF漏洞就是通過篡改獲取資源的請求發送給服務器，但是服務器并沒有檢測這個請求是否合法的，然后服務器以他的身份來訪問其他服務器的資源。

3、SSRF漏洞的用途

• 可以對外網服務器所指向的內網、服務器本地進行端口掃描，獲取一些服務的banner信息
• 攻擊運行在內網或服務器本地的應用程序（比如溢出）
• 對內網web應用進行指紋識別，通過訪問默認文件實現
• 攻擊內外網的web應用，主要是使用get參數就可以實現的攻擊（比如struts2，sqli等
• 利用file協議讀取本地文件等

4、SSRF漏洞的特性

SSRF的強大和成功幾率由函數本身功能決定

即代碼中是什么函數其功能有多強大，那么存在SSRF漏洞的話，漏洞利用的概率和影響力就有多大。比如下面的兩個函數curl_init、file_get_contents：一個能達到執行腳本的地步，一個能達到讀文件的地步。

實例

對于curl_init函數，利用這個遠程包含的特性，使用端口掃描腳本http://192.168.18.62:86/bwApp/evil/ssrf-1.txt去掃描內網ip開放的端口

 

注意：這里為什么txt被執行了，因為這里有個包含漏洞才執行了

對于file_get_content函數：(不支持https，支持http，支持php://內置協議）

讀文件需要base64編碼（php://filter/read=convert.base64-encode/resource=xxx.php）

http://192.168.18.23/pikachu/vul/ssrf/ssrf_fgc.php?file=php://filter/read=convert.base64-encode/resource=../../index.php

 

這里我得總結一下，上面為什么我需要用文件包含去實現我SSRF的目的？，而且為什么要用內置函數去讀文件？，如果是這樣我直接用文件包含不就行了么，簡直跟我文件包含沒有任何區別嘛。

其實這里文件包含是文件包含，SSRF是SSRF，二者之間是本質的不同，一個主要目的是包含文件，一個主要目的是通過中間服務器探測內網信息，這里只是借助了文件包含的能力舉得例子，實際的例子多得很并不都涉及到文件包含，并不能混淆。就好比文件上傳利用文件包含開啟一句話一樣。

以上只是對兩個實例的說明。

其本質是：文件包含了站點web服務器上的東西，而ssrf的目的是打進內網，搞內網的東西。

不懂可以去wooyun看例子，ssrf是借助站點web服務器進入內網進行信息搜集。

5、如何挖掘SSRF漏洞

• 分享：通過URL地址分享網頁內容
• 轉碼服務
• 在線翻譯
• 圖片加載與下載：通過URL地址加載或下載圖片
• 圖片、文章收藏功能
• 未公開的api實現以及其他調用URL的功能
• 從URL關鍵字中尋找

share
wap
url
link
src
source
target
u
3g
display
sourceURl
imageURL
domain
...

6、常用SSRF去做什么事

• 利用執行腳本進行端口探測
• 任意地址訪問
• 內網訪問
• 任意文件讀取
• 內網攻擊

7、繞過方法（繞開一般ssrf的防護）

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://[email protected]/

當后端程序通過不正確的正則表達式（比如將http之后到com為止的字符內容，也就是www.Jeromeyoung.com，認為是訪問請求的host地址時）對上述URL的內容進行解析的時候，很有可能會認為訪問URL的host為www.Jeromeyoung.com，而實際上這個URL所請求的內容都是192.168.0.1上的內容。

8、防護SSRF措施

（1）（黑名單）過濾10.0.0.0/8 、172.16.0.0/12、192.168.0.0/16、localhost私有地址、IPv6地址

（2）（黑名單）過濾file:///、dict://、gopher://、ftp:// 危險schema

（3）使用地址白名單

（4）內網服務開啟鑒權（Memcached, redis, Elasticsearch and MongoDB）

（5）對回顯內容進行識別，采取限制措施

（6）需要使用互聯網資源（比如貼吧使用網絡圖片）而無法使用白名單的情況：首先禁用 CURLOPT_FOLLOWLOCATION；然后通過域名獲取目標ip，并過濾內部ip；最后識別返回的內容是否與假定內容一致

CSRF跨站請求偽造（也叫點擊攻擊）

Cross-site request forgery 簡稱為“CSRF”，在CSRF的攻擊場景中攻擊者會偽造一個請求（這個請求一般是一個鏈接），然后欺騙目標用戶進行點擊，用戶一旦點擊了這個請求，整個攻擊就完成了。所以CSRF攻擊也成為"one click"攻擊。 很多人搞不清楚CSRF的概念，甚至有時候會將其和XSS混淆,更有甚者會將其和越權問題混為一談,這都是對原理沒搞清楚導致的。

1、CSRF攻擊原理

程序員開發的時候，未對相關頁面進行token和referer判斷，造成攻擊者可構造自己的URL地址欺騙目標用戶進行點擊。（點擊后因為未對相關頁面進行token和referer判斷，即鏈接中沒得帶token或者數據包中沒得referer這類的操作，所以鏈接地址沒得校驗操作直接執行了）其實也就是像下面的重要頁面的防范措施沒有做到位

以例子進行說明：

當我們打開網站或者登陸某個網站后，就會產生一個會話(這里指用戶登陸后)，這個會話可能是SESSION，Cookie控制，但是這是無關緊要的。唯一的重點是瀏覽器與服務器之間是在會話之中，在這個會話沒有結束時候，你可以利用你的權限對網站進行操作，如進行發表文章，發郵件，刪除文章等操作。當這個會話結束后，你在進行某些操作時候Web應用程序通常會來提醒你，您的會話已過期，或者是請重新登陸等提示。

這非常好理解，就像我們登陸網上銀行后，Web瀏覽器已經跟可信的站點建立了一個經認證的會話。之后，只要是通過該Web瀏覽器這個認證的會話所發送的請求，都被視為可信的動作，例如轉賬，匯款等操作。當我們在一段時間內不進行操作后，在來重新做轉賬，或者匯款操作，那么這個站點可能會提示你：您的身份已過期，請重新登陸或者會話結束等消息。

而CSRF攻擊則是建立會話之上的攻擊。比如當你登陸了網上銀行，正在進行轉賬業務，這時你的某個QQ好友（攻擊者）發來一條消息(URL)，這條消息是攻擊者精心構造的轉賬業務代碼。而且與你所登錄的網站是同一個銀行，你可能認為這個網站是安全的，并不是什么釣魚網站之類的，然后打開了這條URL，那么你的賬戶的錢可能就在你的這一次小小點擊上全部丟失。

怎么可能這么神奇呢？其實這并不神奇。主要是因為你的瀏覽器正處于與此網站的會話之中，那么一些操作都是合法的，而入侵者構造的這段代碼只不過是正常的轉賬操作代碼而已。比如說你想給用戶spisec轉賬1000元，那么點擊提交按鈕之后，可能會發送以下請求：

http://www.taobao.com/pay.jsp?user=spisec&money=1000

而攻擊者僅僅是改變一下user參數與money參數即可完成一次“合法”的攻擊，如：

http://www.taobao.com/pay.jsp?user=hack&money=10000

當你訪問了這條URL之后，就會自動向hack這個賬戶里面轉入10000元。而這是你親手造成的，并沒因為有人去破解你的密碼或者是Web服務器被入侵所導致的你的金錢丟失。下面以CSRF攻擊原理圖給大家形象總結:

用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A；

在用戶信息通過驗證后，網站A產生Cookie信息并返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A；

用戶未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B；

網站B接收到用戶請求后，返回一些攻擊性代碼，并發出一個請求要求訪問第三方站點A；

瀏覽器在接收到這些攻擊性代碼后，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A并不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。

2、達成CSRF攻擊的條件

• 攻擊建立在瀏覽器與Web服務器的會話之中
• 會話期間需要受害者進行訪問或者說是點擊

如果以上任意一個不滿足都不能達成跨站請求偽造攻擊。即目標必須處于會話狀態，且需要點擊

說白了，CSRF攻擊也就是所謂的釣魚攻擊。

3、CSRF分類

• 站內
• 站外

4、檢測方法

• 手工

檢測CSRF漏洞是一項比較繁瑣的工作，最簡單的方法就是抓取一個正常請求的數據包，去掉Referer字段后再重新提交，如果該提交還有效，那么基本上可以確定存在CSRF漏洞。

• 工具

burp

CSRF Request Builder

CSRFTester

工具檢測的原理：

以CSRFTester工具為例，CSRF漏洞檢測工具的測試原理如下：使用CSRFTester進行測試時，首先需要抓取我們在瀏覽器中訪問過的所有鏈接以及所有的表單等信息，然后通過在CSRFTester中修改相應的表單等信息，重新提交，這相當于一次偽造客戶端請求。如果修改后的測試請求成功被網站服務器接受，則說明存在CSRF漏洞，當然此款工具也可以被用來進行CSRF攻擊。

5、如何挖掘CSRF漏洞

• 掃描器(注意并不是每個頁面爆沒有token漏洞都是對的，因為前端的進行CSRF有毛用，主要就是對后臺管理那一層的，所以不要盲目認為。)，
• 修改密碼的地方
• 添加用戶的地方
• 數據庫備份的地方
• 數據交易、支付等
• 其他一些對話框的釣魚頁面
• CSRF一般與XSS結合使用
• 注意頁面是否帶token或者包中有沒得Referer，Referer在包中刪除是否依然可以訪問url目標等。光靠一個Referer來說也沒用，Referer也能偽造

注意可能有預測的token，即有規律的token，如果是隨機的就放棄吧。

6、常用攻擊手段實例

一般的攻擊思路：（首先，開源的web源碼，攻擊者了解網站的框架，搭建環境構造攻擊url，例如數據備份的，下面實驗中有過程。

去目標網站創建普通用戶，發帖插入url等待目標管理會話在線狀態瀏覽帖子，中招，攻擊者訪問備份下來的數據庫，脫褲，完事。

）

1）、dz網站數據庫備份（快速脫庫）

兩個ip：192.168.18.56:82攻擊者自己的ip、192.168.18.62:86管理員的ip

整體思路：

實驗步驟：攻擊者自己搭建環境，以管理員身份登錄，創建普通賬戶，以管理員身份進行數據備份，抓包，修改包的post數據，構造url為自己要求的。（這里url的IP地址為目標的IP地址）

復制好url，前往目標網站，注冊，以普通用戶身份登錄發帖帶入url（試一下直接在文本中插入，按道理來說需要自動運行地址而不是文本內容），等待管理員登錄且為會話狀態點擊查看攻擊者發帖的內容，達成指定備份。

攻擊者訪問構造的url，脫庫。

攻擊者環境配置url（創建賬號忽略，直接上關鍵步驟）：

 

原本應該這是樣的：

 

 

當攻擊者重構備份的文件夾名稱和文件名的時候：

注意：這里構造是抓到包的時候抓了改，再放包，不是重發器里發一次。

 

 

 

找到攻擊url，構造成目標的地址：

http://192.168.18.62:86/dz/upload/uc_server/admin.php?m=db&a=operate&t=export&appid=0&backupdir=Jerome%26backupfilename%3Dtest

在目標網站上創建用戶、發帖。

 

發帖成功：

 

現在當管理員登錄之后查看帖子，會發現是正常的帖子：

 

 

當管理員在線且點擊了這篇帖子，結果就是數據庫已經達成了備份，且能被攻擊者訪問。

 

這里得說明一下這個路徑，在上面攻擊者搭建的環境中，一定會去模擬攻擊才知道最后的結果在哪個路徑下，上面省卻了這個步驟，這里直接在目標機器上看結果。

 

2）、修改密碼

修改密碼的前提是：利用CSRF漏洞

以dvwa的低級為例，直接抓包：

 

 

上面把referer刪除了，可以改密碼，說明csrf可用。

構造對目標構造如下url，存在CSRF漏洞的情況下，一旦在線點擊訪問就能改密碼：

http://192.168.18.62:86/dvwa/vulnerabilities/csrf/?password_new=password&password_conf=password&Change=Change

 

說一下中級的：

中級的發現無法直接執行再改密碼，先看源碼：

 

 

但通過觀察數據包發現，其沒有referer信息，那么對其進行了一個偽造Referer：

Referer:http://192.168.18.62:86/dvwa/vulnerabilities/csrf/

加入數據包中，發現密碼被修改了。

 

（改密碼也就是說：沒得任何驗證如沒有驗證碼、沒得token、沒得Referer、沒得原密碼校驗等，很容易就造成通殺直接，受害者回話狀態點擊插入了url的地址，直接被修改密碼。）

3）、添加賬號

下面利用一個網站進行添加賬號操作：

首先，利用自建網站進行添加賬號操作，抓包將包生成為poc，建立test.html，廢掉此包。

 

 

目前仍為管理登錄狀態，在這個狀態下點擊了攻擊者的test.html?？聪滦Ч?/p>

 

 

攻擊者的效果成功達成。

4）、自解壓縮包

配置方式如下：

 

 

一旦解壓就會打開百度，自行嘗試吧。

7、防范方法

• 驗證HTTP Referer字段
• 在請求地址中添加token并驗證
• 在HTTP頭中自定義屬性并驗證
• 在服務端嚴格區分好POST和GET的數據請求
• 使用驗證碼或者密碼確認方式進行
• 白名單