It is a well-known fact that Web applications can trigger requests between different HTTP servers. This is usually done to fetch remote resources like software updates or to import metadata from a specific URL or another web application. Under ordinary circumstances, such inter-server requests are safe. However, if implemented incorrectly, it can render the server vulnerable to Server Side Request Forgery.

  1. What is SSRF attack
  2. Impact of SSRF attacks
  3. Server-side Request Forgery (SSRF) prevention

1) What is SSRF attack

Server-Side Request Forgery/ SSRF is essentially a web security vulnerability that allows an attacker to stimulate a server-side application that is not externally accessible to make HTTP requests to an arbitrary domain of the attacker’s choosing.

Sometimes there are needs to retrieve information from a web application; this could be internal sources such as RSS feed on another website or server sider requests to fetch the resource and include it in the web application. For example, in an SSRF attack against the server itself, a developer can use a certain URL to retrieve the remote feed. If the attacker can change the URL parameter, he can view the local resources hosted on the server, making said server vulnerable.

This means that in the event of a successful SSRF attack, the attacker can change a parameter used on the web application in a mala fide manner to create or control requests from the vulnerable server. Such control can result in the following adverse actions:

  • Abuse of the trust relationship that exists between the now vulnerable server and other machines. To elucidate, at a network level, there exists a trust relationship that would be exploited by an SSRF attack is that of a firewall allowing only trusted IP address or networks being allowed access. It would be the exploiting of leniency at a software level allowed in lack of the need for permission to access information for administrative tasks. This is the most common kind of SSRF attack.
  • Bypassing of IP whitelisting
  • Bypassing host-based authentication services.
  • Access to resources and information that is not normally accessible to the public. E.g., access to trace.axd in ASP.NET or metadata APIs in an AWS environment or Internal REST interfaces.
  • Scan the internal network to which the server is connected to. When the content of a remote resource is directly rendered to a page, the attacker may be able to read the content of the files.
  • Access to files from the webserver
  • Ability to view status pages and interact with APIs as the webserver.
  • Ability to retrieve sensitive information as the IP address of the webserver behind a reverse proxy.

In a typical instance of SSRF Attack, the attacker has to send a request to the vulnerable web server that abuses SSRF vulnerability. The web server then makes a request to the victim’s server which sits behind a firewall. This would entail a response with data from the Victim’s server. Now, if the specific SSRF vulnerability permits it, the data is sent back to the attacker. This is how an attacker scans an internal network. The reason behind said actions are that the attacker cannot send direct requests to the victim’s server, because a firewall blocks them.

2) Impact of SSRF attacks

It is pretty clear from the above explanation that the most resulted outcome/ impact of exploiting SSRF vulnerability is information disclosure of an organization via unauthorized actions, such as:

1.     The possibility to scan ports and IP addresses.

2.     Interaction with some protocols such as Gopher which allows one to make further discoveries.

3.     Discovering the IP addresses of servers running behind a reverse proxy.

4.     Execution of code remotely

There are several consequences to SSRF attacks, some that are more severe than others. This is mainly dependent on how the web application uses responses from the remote resource.

3) Server-side Request Forgery (SSRF) prevention

It is necessary to circumvent SSRF behaviours. Defences must be taken against the malicious exploitation of information that should not be available to anyone without authorized access.

  • Deduction: The first question is how to find ssrf vulnerability. The way to deduct SSRF is by using an out of band vulnerability scanner.
  • Mitigation: Simple blacklists and regular expressions applied to user input is a bad approach to mitigate. Blacklisting can be easily bypassed through HTTP redirects, wildcard DNS services such as or even alternate IP encoding. The right method would be whitelisting, whereby the access is given only to DNS names or IP address that has been whitelisted. It is important to note here that the validation of user input is necessary.
  • Response handling: To prevent the response data that is provided on request for access is not leaked to the attacker, one must ensure that the received response is as expected or previously agreed upon. Under no circumstances should a raw response body be granted the request it seeks for.
  • Disable unused URL schemas: If an application only uses HTTP or HTTPS to make requests, only such URL schemes are to be allowed. If unused URL schemas are disabled, the attacker will not be able to use the web application to make requests using potentially dangerous schemas such as file://, dict://, ftp:// and gopher://. 
  • Authentication on internal services: Most services such as Memchand and Redis do not require authentication by default. This would allow an attacker to use SSRF vulnerabilities to access some services without any authentication with ease. Therefore, to ensure the security of web application and services, it is ideal that one enables authentication wherever possible, even for services on the local network.


In brief, an SSRF attack can abuse the functionality on the server to read or update internal resources while destroying trust relationships as well. Through said SSRF attack, one can not only read server configuration but to a certain extent will also be able to read the contents of files which they obtain unauthorized access to. It is necessary to take all necessary precautions to ensure that there is no unwarranted or unauthorized access to information of an organization or individual stored in a web application.

So, have you made up your mind to make a career in Cyber Security? Visit our Master Certificate in Cyber Security (Red Team) for further help. It is the first program in offensive technologies in India and allows learners to practice in a real-time simulated ecosystem, that will give them an edge in this competitive world.



Are you ready to build your own career?