How to protect yourself against Server Side Request Forgery
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 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
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
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:
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://126.96.36.199 &@188.8.131.52# @184.108.40.206/
At the time of his analysis, the libraries urllib2 and httplib declare
220.127.116.11 as valid IP address. However, the library requests interprets the IP address
18.104.22.168 as the valid address. Finally, the library urllib claims the IP address
22.214.171.124 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:
http://2130706433(decimal IP address)
http://0x7F000001(hexadecimal IP address)
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.
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.
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here