什麼是服務端僞造（SSRF）

 

什麼是服務端僞造（SSRF）

原文：GitHub Pages and Single-Page Apps

譯者：neal1991

welcome to star my articles-translator , providing you advanced articles translation. Any suggestion, please issue or contact me

LICENSE: MIT

服務端僞造（SSRF）指的是攻擊者從一個具備漏洞的web應用中發送的一個僞造的請求的攻擊。SSRF一般適用於針對在防火牆後通常對於外部網絡的攻擊者是沒法訪問的內部系統。另外，攻擊者也可能利用SSRF來訪問監聽回送地址接口（127.0.0.1）的服務。

典型的SSRF發生在web應用發送請求的時候，攻擊者對這個發送的請求具備所有或者部分的控制。一個通用的例子就是攻擊者可以控制所有或者部分web應用向第三方服務發送請求的URL。

下面的是PHP中容易收到SSRF的一個例子。

<?php

/** * Check if the 'url' GET variable is set * Example - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif */
if (isset($_GET['url'])){
$url = $_GET['url'];

/** * Send a request vulnerable to SSRF since * no validation is being done on $url * before sending the request */
$image = fopen($url, 'rb');

/** * Send the correct response headers */
header("Content-Type: image/png");

/** * Dump the contents of the image */
fpassthru($image);
}

在上面的例子中，由於攻擊者對於url參數具備完整的控制，所以可以對於網上的任何網站都可以發送任意的GET請求。攻擊者也可以向服務器中的資源發送請求。

好比，攻擊者可能可以訪問本地的服務。在下面的例子中，攻擊者經過開啓mod_status（默認開啓）可以在Apache HTTP服務器上發送下面的請求。

GET /?url=http://localhost/server-status HTTP/1.1
Host: example.com

相似的，SSRF可以被用來請求這個web服務器能夠訪問的其它內部資源，可是這些資源不是對公共開放的。這個樣的例子好比是在Amazon EC2 以及 OpenStack 上訪問實例元數據。這個服務僅僅向服務器開放而不是外部世界。攻擊者甚至會有更多發現經過使用這個方法在內部網絡中運行端口掃描。

GET /?url=http://169.254.169.254/latest/meta-data/ HTTP/1.1
Host: example.com

除了經過http://以及·https://URL協議，攻擊者可能也利用少數人或者遺留的URL協議來訪問內部網絡的本地系統中的文件。

下面的例子就是利用file:///URL協議來發送這樣的請求。

GET /?url=file:///etc/passwd HTTP/1.1
Host: example.com

根據應用如何產生請求，攻擊者可以利用URL協議而不是文件以及HTTP。好比，若是cURL被用來產生請求（上面的例子這就是利用fopen()來發送請求），可能可以利用dist URL協議向任何主機的任何端口發送請求而且發送自定義的數據。

GET /?url=dict://localhost:11211/stat HTTP/1.1
Host: example.com

上述的請求會形成應用連接到主機的11211端口而且發送字符串」stat」。端口11211是Memcached（一般不會暴露）使用的端口。對於一個能夠利用的綜合攻擊列表以及URL協議，ONSec實驗室維護了一個具備關於SSRF攻擊有用的詳細文檔。

檢測SSRF

爲了自動檢測SSRF，咱們須要依靠中介服務，由於檢測到這樣一個漏洞須要一個帶外和延時的向量。Acunetix經過在自動掃描是講AcuMonitor 做爲它的中介服務來解決這個問題。

在這個掃描期間，Acunetix將會產生一個包含一個特殊AcuMonitor URL的請求。若是AcuMonitor接受到一個包含以上一個特殊URL的請求，它會發送一個通知到Acunetix告訴它應該對於SSRF發出警告。

下面的是Acunetix利用AcuMonitor掃描來檢測SSRF的結果。這個警告包含了正在執行的HTTP請求的信息，包括髮送這個請求的IP地址以及這個請求使用的User-agent字符串。這個信息能夠幫助開發者識別問題的來源而且進行修復。

避免SSRF

白名單和DNS解析

直接在用戶的輸入上實時簡單的黑名單或者正則表達式來過濾IP地址或者域發送的這個請求，這對於避免SSRF是一個壞方法。

一般，黑名單都是一個糟糕的安全控制由於老是會有開發者忽視的漏網之魚有。在這樣的狀況下，攻擊者就可以利用這樣的旁路來產生HTTP重定向，一個通配符DNS服務好比xip.io或者甚至是可用的IP編碼.

相反，最通用的解決SSRF的方式是使用你的應用須要訪問DNS名稱或者IP地址的白名單。若是白名單方案不適合你的用戶案例，那麼你必須依賴黑名單，適當地驗證你的用戶輸入是很是重要的。一個例子就是不容許向私有IP地址（非路由）發送請求（詳細參考RFC 1918），然而，在使用黑名單的狀況下，正確的採起什麼樣的避免措施每每取決於具體的應用。換句話說，對於SSRF沒有一個通用的修復方法，由於它很是依賴於應用的功能以及商業需求。

響應處理

確保響應是遠程服務器接收的響應是它應該接收的是很是重要的，這對於阻止響應數據意想不到的泄露給攻擊者是很是重要的。以上其餘的，不管在任何狀況下，服務器發送的原生響應體都不該該直接發送給客戶端。

關閉無用的URL協議

若是你的應用僅僅使用HTTP或者HTTPS來發送請求，那麼應該就僅僅容許這些URL協議。關閉不使用的的URL協議可以阻止web應用使用潛在危險的URL協議，好比file:///，dict://，ftp://以及gopher。

認證內部服務

服務好比Memcached，Redis，Elasticsearch以及MongoDB默認不須要認證的。SSRF漏洞能夠提供給攻擊者一個沒有任何認證阻攔的機會來訪問這些服務。所以，最好實在人地方都使用認證，這也是一個防禦機制。

 

能夠掃描二維碼或者搜索 mad_coder 關注微信公衆號，點擊閱讀原文能夠獲取連接版原文。