With the advancement and adoption of new techniques to exploit web application vulnerabilities, attackers have found new ways to pervade firewalls to attack the internal systems which are generally not accessible to the attackers from the external network. One of such attack is Server Side Request Forgery. Adding to that, SSRF can also be further leveraged to access different services running on the server on the loopback interface.
Server-Side Request Forgery (SSRF) being a kind of attack where the attacker crafts malicious request from the client (Web application) according to his/her motive to send it finally to the server. For example, the attacker can make a request by changing or manipulating the URL to any third party website.
A few actions that can be performed using SSRF are:
- IP whitelisting can be bypassed.
- Port scanning of the internal network to which the server is connected.
- Accessing file on the internal server using legacy URL schemas.
- Sensitive information IP address of the web server can be retrieved which is normally behind the reverse proxy.
- Remote code execution from the client side.
How is SSRF used to exploit?
File contents on the server can be remotely read and accessed using different URL schemes by exploiting SSRF vulnerability.
Using file:// URI schema instead of https:// or  local files internal to the server can be read or further exploited. For example using the URI file:///etc/passwd password file to the UNIX system could be printed to the page. A similar technique can be further used to view the source code of the vulnerable application.
SSRF can further be deployed for exploiting an application other than URL schemas of the file, HTTP or HTTPS, dict URL schema being one of them which is used to make a request to any host on any port and thereby send customized data.
Suppose let us consider the below request
GET /?url=dict://localhost:11222/Hacker HTTP/1.1
In the above request we are connecting the application to Memcached which is an open source memory object caching system, where 11222 is the port used by Memcached and sending the string ‘Hacker’ through the above request and thus in a way we will end up caching any arbitrary string or malicious code, which was not a part of any valid genuine request.
How to detect SSRF?
SSRF is generally rendered to delve deeper into the functioning of the server and the internal network of the web server (where it is hosted), and also about the other services hosted on the network, thus making SSRF a niche and part of an Out-of-bound class of vulnerabilities. Detecting SSRF is no child’s play and manual intervention seldom proves to be useful in finding the vulnerability, so it requires a scanner in most of the cases, where an intermediate request is sent to the intermediary AcuMonitor service (in the case of using Acunetix as the tool).
Now we can use the server as a proxy, but however, for obtaining information about the server itself, HTTP/HTTPS request needs to be taken by the Acunetix Scanner. When we run a scan in Acunetix it will make requests which contain unique AcuMonitor URL. If any one of these requests containing the unique URL is received by the AcuMonitor, it will then send a notification to Acunetix indicating that the server is prone to SSRF.
Other open source tools like IronWASP and Skanda is also available to root out SSRF vulnerability. Skanda can be used to detect network hosts, service, to detect open ports thereby further exploitation through SSRF.
Avoiding blacklist and simple regular expression. This is because in the case of blacklisting there would always be bypass strategies which might not have been envisaged by the developer. So it turns out that sending crafted request to the server would be as simple as using an HTTP redirect. So instead of using a blacklist, the developers should always try out whitelisting the DNS name and IP addresses required by the application. However if a whitelist approach does not serve your applications’ need, you must validate user input correctly, for example, request/response traffic should always be blocked in case of private (non-routable) IP addresses. Although the main approach to mitigate SSRF would always depend upon the functionalities of the different application.
Generic error messages should be displayed to the clients as unhandled responses might end up revealing sensitive information or data leakage about the server when any raw response is sent.
Responses received from the remote side should always be validated and this is the most basic mitigation process that should be implemented. For e.g. data types should be checked on the server side properly before further processing or sending the data to the client.
URL schemas other than HTTP and HTTPS should be blacklisted, rather these two mentioned protocols should be whitelisted thereby not allowing other schemas which are not in use like file:///, dict:// and ftp:// which might prove to be dangerous for SSRF.
Enabling authentication to services like Memcached, Redis, Elastic search and MongoDB is another defense mechanism against SSRF.