OWASP
5.2.6 insufficiently protects against SSRF
5.2.6 Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.
Consider an application where it is allowed to load arbitrary resources from the internet. It should not be allowed to load resources from localhost or the local network. This can't be performed by only checking user input, because the user could input a domain that resolves to localhost. The correct solution is to resolve the domain, check the IP, and then use that same IP to connect. In practice, this means the HTTP library needs to have functionality to protect against SSRF, to perform a check between DNS resolution and connection.
If the IP is validated beforehand, but then resolved again when connecting, SSRF may still be possible using a DNS rebinding attack, where the first resolution returns something else than the second resolution.
Also, redirects from an allowed domain to localhost should be blocked.
So using "allow lists of protocols, domains, paths and ports" is good advice, but it is insufficient to block all types of SSRF.
The goal for 5.2.6 is clearly and only user input sanitize/validation.
What you described here is more second layer of defense and we have related issue for that: https://github.com/OWASP/ASVS/issues/1324
For me it seems, that if you want to get those improvements into a requirement, those should go to configuration hardening category and to current 12.6.1.
If it already goes to messing with DNS, it feels out of ASVS scope for me.
The attack scenario is as follows:
An application has the functionality to load files from the internet. On its local network is also an API server or Redis server. The attacker inputs "https://attacker.com/" to load a resource from. This passes validation, because it seems like a host on the internet. The attacker either:
- Configures the DNS of attacker.com to resolve to 192.168.1.123, routing the request to the server on the local network as the application server.
- Redirects to "https://192.168.1.123/", also rerouting the request to the local network.
And that results in SSRF.
Input validation won't help, because the attacker supplied a valid URL. Firewall configuration won't help, because the application server needs to communicate with the API server or Redis server for normal functionality. The solution is to use something like advocate or safecurl, which validate the host after resolution and upon redirect.
I don't think we currnetly have a requirement to protect against this attack.
Like I said, if it is related to messing with DNS, it's out of ASVS scope.
And proposals and descriptions are more related to 12.6.1 or material for new requirement. I think requirement 5.2.6 is valid and can stay like it is?
Like I said, if it is related to messing with DNS, it's out of ASVS scope.
Can you elaborate on this? I don't understand why this would be the case.
Configures the DNS of attacker.com to resolve to 192.168.1.123, routing the request to the server on the local network as the application server.
How attacker can do that for the targeted server?
In my scenario, the attacker owns attacker.com, so they can just configure the DNS in the normal way anyway they want.
And how the attacker.com got into the allow-listed domains?
In my scenario, the attacker owns attacker.com, so they can just configure the DNS in the normal way anyway they want.
If they configure their DNS, it does not mean that the target server is using their DNS to solve names.
Only thing what I can pick up from here as extra defense is that loading resources from external serveris should not follow redirects.
Some applications allow loading any image by URL.
In this case, the server loads a user-input URL. But to avoid SSRF it should not load resources from the local network.
There is no meaningful allow list of domains in this case, since any host on the internet is permissable.
Alternatively, even if there is a strict allow list, the domains on the allow list should not be able to perform SSRF by changing their DNS records.
If you provide for every user to access whatever address, then it must be accepted risk based on business logic rule. How to make potential impact lower for this kind of case it's a good question.
I still don't get your DNS topic here - for me it is out of ASVS scope. If you can change someone's DNS, some tiny SSRF is not your main problem. Or I just don't get it - how you can change someones DNS records the that it is in the ASVS scope?
- onfigures the DNS of attacker.com to resolve to 192.168.1.123, routing the request to the server on the local network as the application server.
URL validation is not enough for SSRF protection. You need to whitelist valid domains and patterns. URL validation and domain verification are the wins here. Attacker.com should not be on any SSRF allow-list.
There is no meaningful allow list of domains in this case, since any host on the internet is permissable.
I see your scenario. But if you allow a server to load any resource on the internet, you are already screwed. That is not reasonable for any enterprise app.
The solution is to resolve the domain, validate that the resulting IP address is not an RFC1918 IP address, and then connect to that IP address. To avoid race conditions, only one domain resolution must be performed. This validation has to be done again when a redirect occurs.
But if you allow a server to load any resource on the internet, you are already screwed.
I disagree with you here, but that doesn't really matter for this issue. Domains that are legitimately on the allow list should also not be able to redirect requests to the server's network.
SSRF defense is complex and likely merits its own section and should be removed from the validation section. Perhaps 5.2.6 goes away:
| 5.2.6 | Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports. | ✓ | ✓ | ✓ | 918 |
|---|
And is replaced by a new SSRF section that covers:
- Proper URL validation strategies (hat tip to @Sjord for his astute comments above)
- Proper URL creation strategies (such as "https://server.com/" + urlEncode(data))
- Network limitations for outbound service calls
- and perhaps more. SSRF is complex.
- Network limitations for outbound service calls
It is covered by current 12.6.1 and has opened issue https://github.com/OWASP/ASVS/issues/1324
Its already being discussed so I closed it, I did not mean to do a duplicate.