Remediation advice in SSRF could be more broadly focused

[PhilipAtCisco]

Description of the issue

The remediation advice for how to mitigate SSRF vulnerabilities is focused on URL allowlisting. While this is fairly good for https schemes where possible to implement, it's not really a comprehensive defense for SSRF.

The advice given assumes that an attacker can't manipulate DNS entries for the domain being allowlisted. It also doesn't offer any advice for mitigating SSRF if an attacker has complete control of the URL and an allowlist isn't practical.

It would be good to add a sentence to the advice to make the remediation advice less specific. Perhaps incorporating a mention of additional network or application controls to prevent servers from making connections to internal resources in the first place (e.g. based on IP addresses).

https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

[Kwstubbs]

Hi Philip,

The advice given assumes that an attacker can't manipulate DNS entries for the domain being allowlisted.

I don't see how this is relevant to the SSRF present on the vulnerable application.

It also doesn't offer any advice for mitigating SSRF if an attacker has complete control of the URL and an allowlist isn't practical.

We want the docs to be easy to understand. Do you know if there is any way to get the IP address of the URL in the same request that grabbed the server contents? Otherwise to properly check the IP address gets more complicated than can be described in a help doc. I can look into it in the coming weeks.

Perhaps incorporating a mention of additional network or application controls to prevent servers from making connections to internal resources in the first place (e.g. based on IP addresses).

Sure, I'll add a statement about network segmentation.

[PhilipAtCisco]

Hi @Kwstubbs,

The advice given assumes that an attacker can't manipulate DNS entries for the domain being allowlisted.
I don't see how this is relevant to the SSRF present on the vulnerable application.

It's relevant in cases where scheme is not being validated to be https (e.g. partial SSRF and the attacker can e.g. use http) or there is no certificate validation on an https request, and an attacker can control the DNS responses such that they can probe the network or do other things using the SSRF vulnerability. Definitely harder to do.

We want the docs to be easy to understand. Do you know if there is any way to get the IP address of the URL in the same request that grabbed the server contents? Otherwise to properly check the IP address gets more complicated than can be described in a help doc. I can look into it in the coming weeks.

Thanks. This would be pretty language dependent. Understood, regarding making the docs easy to understand. Typically when IP address blocking needs to happen in the application layer instead of a network layer, I've seen it stopped at a different level (e.g. connectors configured with rules that block requests where the resolved IP is https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Address.is_private ).

Sure, I'll add a statement about network segmentation.

Thanks