Server-Side-Request-Forgery - What it is and how to protect yourself

Server-Side-Request-Forgery

What it is and how to protect yourself

Andrea Hauser
by Andrea Hauser
time to read: 8 minutes

Keypoints

How to protect yourself against Server Side Request Forgery

  • Server-Side-Request-Forgery is abbreviated as SSRF
  • This is an attack technique that tricks a server into making requests controlled by the attacker
  • Attacks can be made against the internal network, the vulnerable server itself, or external third parties
  • Protecting against this is not trivial, as evidenced by the fact that the definition of what a valid IP address or URL is is not always the same, even by libraries

Server-Side-Request Forgery (SSRF) causes a server to trigger requests controlled by attackers. The resulting requests can be routed to the vulnerable server itself, to other internal systems or even to external third-party systems, depending on the firewall settings. Among other things, this can make it possible to access internal data or trigger internal actions. In the worst case, the SSRF vulnerability can even lead to remote code execution. If the requests are sent to an external third-party system, an attacker can use them to make the vulnerable server look like the culprit and remain completely unknown to the third-party system.

Basically, all features that trigger requests where the recipient of the request depends at least partially on user input can be vulnerable. However, the following areas are features that are often vulnerable to SSRF:

SSRF against the Server itself

SSRF attacks against the vulnerable server itself, the server is tricked into sending a request to its own loopback interface. The original URL in the request is replaced by 127.0.0.1 or localhost, for example. Since the triggered request comes from an internal source and no longer from an external one, it is possible that more information can be accessed. An attacker could also attempt to use SSRF to find the open ports of the vulnerable server. Since an internal connection is assumed here again, it is possible that more open ports can be determined and that interfaces that are only internally accessible can be approached.

However, an attacker is not necessarily restricted to HTTP and HTTPS requests. If an attacker can control the full URL, he can also change the schema. And thus use file:// to access files on the vulnerable server. Other remarkable schemas are for example ftp:// and gopher://.

SSRF against the Internal Network

Similar to the vulnerability of the server itself, requests can be sent to the internal network to create a port scanner for it. What makes this more difficult for an attacker is that the internal network range is probably not known. An attacker must first find out this private network range. This is different if the server is located in the cloud. Because there are other attack targets, such as the AWS and Google Cloud Metadata Endpoints. These endpoints can even be used to find access tokens. In the worst case scenario, these access tokens can be used to access the entire environment of a company in the cloud. Some examples of interesting cloud metadata URLs are the following:

Circumvention of SSRF Countermeasures

If it is necessary to derive URLs or domains from user input, it is not easy to effectively protect against SSRF attacks. One reason for this is that – as studies by Orange Tsai show – not even libraries agree on how to interpret certain IP addresses or URLs. In his research he shows, for example, that the following URL is interpreted differently by different Python libraries:

http://1.1.1.1 &@2.2.2.2# @3.3.3.3/

At the time of his analysis, the libraries urllib2 and httplib declare 1.1.1.1 as valid IP address. However, the library requests interprets the IP address 2.2.2.2 as the valid address. Finally, the library urllib claims the IP address 3.3.3.3 to be valid. Thus, if different libraries are used in the code to check IP addresses and execute the effective requests, a combination of these interpretations may allow an attacker to bypass IP address limitations.

However, this is not the only trick that can be used to bypass careless SSRF countermeasures. It is also possible to attempt to write an IP address in different ways. All the examples shown below are IP addresses that connect to localhost:

An attacker can still use DNS as well. If external DNS requests can be triggered by the attacker, an attacker can respond to a DNS request with any IP address. For example, if the attacker controls evil.com and is requested to disclose the IP address for this domain, the attacker can reply with 127.0.0.1, thus bypassing any restrictions.

Effective countermeasures

As mentioned above, it is not easy to protect yourself effectively against SSRF attacks. In principle, it should always be clarified first whether user input is actually required for the creation of a domain, URL or IP address. As far as possible, it should not be possible for users to control these entries. However, if it is not possible to implement this, a distinction must be made between two approaches. On the one hand, there are cases in which only known and trustworthy applications need to be controlled by the server. In this case a whitelist approach should be chosen to check the user’s input. In addition, it should be ensured at network level that only the necessary servers are actually accessible. On the other hand, there are cases where the external domains and IP addresses cannot be restricted because the target servers are unknown to the application. This is the case, for example, if WebHooks are offered. In these cases no whitelist approach can be used, accordingly the concept of a blacklist is used. It must be made clear that a blacklist is never as effective as a whitelist. Accordingly, it is even more important that such servers are located in a separate zone, so that an attacker cannot gain access to the internal network if the blacklist is circumvented.

More detailed explanations about countermeasures against SSRF can be found in the OWASP Cheat Sheet Server-Side-Request-Forgery Prevention.

Conclusion

Server Side Request Forgery is a vulnerability that can be exploited in many ways. Accordingly, the effects can range from enumeration of internal services to access to internal information to remote code execution. The server itself, the internal network and external third parties are vulnerable. To protect against SSRF, user entries in URLs, domains or IP addresses should not be used whenever possible. If user input is necessary, a whitelist procedure should be used and it should be ensured at network level that only necessary access is actually possible.

About the Author

Andrea Hauser

Andrea Hauser graduated with a Bachelor of Science FHO in information technology at the University of Applied Sciences Rapperswil. She is focusing her offensive work on web application security testing and the realization of social engineering campaigns. Her research focus is creating and analyzing deepfakes. (ORCID 0000-0002-5161-8658)

Links

Tags

AWS Cloud Exploit Firewall GitHub Google Hacker HTTP Master OWASP Payload Report Request Research Scan Shop South Trust Video Word XML

You want to test the security of your firewall?

Our experts will get in contact with you!

×
Prompt Injection

Prompt Injection

Andrea Hauser

Ways of attacking Generative AI

Ways of attacking Generative AI

Andrea Hauser

XML Injection

XML Injection

Andrea Hauser

Burp Macros

Burp Macros

Andrea Hauser

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here