Server Side Request Forgery (SSRF) is simply an attack where the server will make a request (act like a proxy) for the attacker either to a local or to a remote source and then return a response containing the data resulting from the request.
We can say that the concept of SSRF is the same as using a proxy or VPN where the user will make a request to a certain resource, then the proxy or VPN Server will make a request to that resource, then return the results to the user who made the request.
From SSRF, various things can be done, such as:
For the use of the lab in this blog post, only use the simple script below (of course maybe the application in Real World is not as simple as this) and will be deployed on Digital Ocean.
<?php
$url = $_GET['url'];$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER,1);
curl_setopt($curl, CURLOPT_TIMEOUT, 5);
curl_setopt($curl, CURLOPT_CONNECTTIMEOUT, 5);$data = curl_exec ($curl);if(curl_error($curl)){
echo curl_error($curl);
}else{
echo "<pre>" . $data . "</pre>";
}
curl_close ($curl);
?>
Curl
was chosen as the requester for this blog post because curl
supports various protocols, so it's good for learning purpose.
requestster is a function or library that we use to fetch/request of the resource from input URL.
The purpose of scanning a port is simply to be able to map running applications/services behind that port so the attacker can identify what applications/services are running on that port. This becomes very important if the attacker wants to interact and then perform querying to internal applications/services.
Port scanning can be done using HTTP, HTTPS, GOPHER, or DICT protocols.
If there is a Blind SSRF to find out whether the port is open or closed, you can pay attention to Content-length, Response Time, or HTTP Status Code.
The indicator to find out, of course, is not just the three elements mentioned above, there could be “unusual” elements that appear during port scanning because it depends on what technology and what environment the web application uses.
HTTPS protocol if the port is open the response time will be longer because HTTPS will do the handshake, therefore the use of the HTTPS protocol can be a suitable choice for port scanning when faced with Blind SSRF
In the context of SSRF accessing/reading Local Files can only use the file:///
protocol, but not all requesters support the file:///
protocol. Besides, there may be a hard filter/blacklist that does not allow the use of that protocol, but still, it depends on the behaviour of the requesters.
To access the file itself, you can use file:/PathToFile
, file:///PathToFile
or file://hostname/PathToFile
. The three access methods are valid URIs for file:///
.
If the web application is deployed on Windows Server, to access files using the file:/// protocol, you can use file:///<drive_letter/PathToFile. Example : file:///d:/hello.txt
The real power of SSRF is where the attacker can interact with the internal application/service/network in Local Network, imagine if there is a vulnerable application/service in the internal network where the attacker cannot reach the application/service because it is on a different network, but if there is SSRF vulnerability the Attacker might be able to do that.
If the requester supports the use of the gopher://
protocol or there may be a CRLF Injection
vulnerability, it will allow attackers to interact with various internal services such as SMTP
, MySQL
, Redis
, Memcached
and so on. Then querying these services to give the desired command, for example, to read local files or even to get RCE.
Gopher is classified as a universal protocol, through gopher the attacker can do smuggling to other protocols, besides that gopher also supports the use of newline (\r\n) so that even though the requestster is not vulnerable to CRLF Injection, the attacker can still perform CRLF Injection because Gopher does support multiline requests.
A blog post on how to interact with internal services can be read in separate material below:
There are various vendors that provide cloud computing services such as AWS, Azure, Google Cloud, Digital Ocean, etc. where these vendors provide Metadata access using REST API, but the REST API can only be accessed through the cloud network.
If a vulnerable SSRF web application is deployed in one of those Cloud Services, it will be very possible for an attacker to access Metadata information by exploiting the SSRF vulnerability.
References to REST API endpoints can refer to the official documentation of the cloud service provider used or can see the Cloud Metadata Dictionary useful for SSRF Testing by BuffaloWill.
Reflected XSS can occur if you are not faced with Blind SSRF.
XSS on Blind SSRF can happen if the requester supports javascript, for examples like PhantomJS
and Selenium
, then it’s not impossible for an attacker to do a DNS Rebinding
Attack to “play” with internal services/networks.
List of requesters that support various protocols :
(Source: SSRF bible. Cheatsheet by Wallarm)
List some protocols that support for smuggling to other protocols :
(Source: SSRF bible. Cheatsheet by Wallarm)
CRLF Injection
, because this becomes important if the attacker wants to query the internal service