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

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

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

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

舉個(gè)例子

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

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

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

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

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

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

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

如何預(yù)防SSRF攻擊

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