如何理解服務(wù)器端請求偽造（SSRF）類漏洞

當服務(wù)器向用戶提交的未被嚴格校驗的URL發(fā)起請求的時候，就有可能會發(fā)生服務(wù)器端請求偽造（SSRF，即Server-Side Request Forgery）攻擊。

SSRF是由攻擊者構(gòu)造惡意請求URL，由服務(wù)端發(fā)起請求的安全漏洞。攻擊者可以利用SSRF漏洞來攻擊到內(nèi)部系統(tǒng)，因為服務(wù)器請求天然發(fā)生在系統(tǒng)內(nèi)部。SSRF 形成的原因大都是由于服務(wù)端提供了從其他服務(wù)端應(yīng)用獲取數(shù)據(jù)的功能，但又沒有對目標地址做校驗與限制。

應(yīng)用程序為了給用戶提供更多更方便的功能，從另一個URL獲取數(shù)據(jù)的場景越來越多，因此SSRF漏洞也越來越多。此外，由于云服務(wù)和體系結(jié)構(gòu)的復(fù)雜性，SSRF攻擊產(chǎn)生的影響也越來越大。

舉個例子

假設(shè)一個電商網(wǎng)站，展示商品詳情的時候也同時展示庫存數(shù)量，庫存數(shù)量需要提供商品詳情信息的后端服務(wù)通過REST API查詢其他后端服務(wù)得到，而其他后端服務(wù)的URL地址直接包含在查詢商品詳情的接口中，作為此接口的一個參數(shù)。所以展示商品詳情界面會發(fā)出如下請求：

POST /product/detail HTTP/1.0
Content-Type: application/json

{"productId:66","stockApi":"http://stock.xxx.com/stock/detail"}

這種情況下，攻擊者可以通過修改請求參數(shù)stockApi以指定任意URL，例如：

POST /product/detail HTTP/1.0
Content-Type: application/json

{"productId:66","stockApi":"http://localhost/admin"}

此時，服務(wù)端就會訪問http://localhost/admin并將其內(nèi)容返回給用戶，攻擊者就可以采用這用方式來嘗試獲取到服務(wù)器相關(guān)的信息。

如何預(yù)防SSRF攻擊

• 嚴格校驗用戶輸入的URL，可以使用白名單過濾來限制輸入，只允許特定的協(xié)議、主機和端口。
• 不要把原始的響應(yīng)數(shù)據(jù)返回給客戶端。
• 限制Web應(yīng)用程序的網(wǎng)絡(luò)訪問權(quán)限，可以讓遠程資源訪問功能使用單獨的網(wǎng)絡(luò)。
• 限制Web應(yīng)用程序?qū)Ψ?wù)器端資源的訪問權(quán)限，可以使用訪問控制列表（ACL）來限制應(yīng)用程序可以訪問的URL和端口。
• 加強代碼審核，通過人工審核和自動化審核工具審核的方式來發(fā)現(xiàn)潛在的SSRF漏洞。