OWASP / Top10

Official OWASP Top 10 Document Repository
Other
4.32k stars 833 forks source link

Update A10_2021-Server-Side_Request_Forgery_(SSRF).md #589

Closed sslHello closed 3 years ago

sslHello commented 3 years ago

Added some content:

sslHello commented 3 years ago

@orangetw could you review my additional content, please? And give us your opinion?

orangetw commented 3 years ago

Hi, thanks for the update. Here are my feedbacks

Log all accepted and blocked network flows (see A09:2021-Security Logging and Monitoring Failures). Establish an ownership and a lifecycle for firewall rules based on applications

As this section is about "How to Prevent", I am not sure the logging and monitoring fit to this section.


Don't deploy other security relevant services on front systems. Control local traffic on these systems (e.g. localhost)

Is there any different between the Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic and this?


For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independant systems to consider very high protection needs

I don't understand why VPN can prevent the system from SSRF

Please let me know your opinions, thanks! :D

sslHello commented 3 years ago

@orangetw Thank you so much for writing A10 and your feedback. Here my answeres ;-)

Log all accepted and blocked network flows (see A09:2021-Security Logging and Monitoring Failures). Establish an ownership and a lifecycle for firewall rules based on applications

As this section is about "How to Prevent", I am not sure the logging and monitoring fit to this section.

Outdated firewall rules could be used with SSRF to access services that were out of scope when deploying a new service. Logging all accepted and blocked network flow on firewalls could help to detect SSRF (by A-09). I suggested to add it, as it might not immediately obvious. Infrastructure and applications should work here together.

Don't deploy other security relevant services on front systems. Control local traffic on these systems (e.g. localhost)

Is there any different between the Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic and this?

Here I've had in mind to protect that services on localhost could be attached by SSRF (additionally to other servers)

For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independant systems to consider very high protection needs

I don't understand why VPN can prevent the system from SSRF

If you have a B2B application or Remote Access for your employees this might not reduce SSRF itself but the attack vector about who is able to attack your applications througt SSRF.

How do you think about it? Cheers Torsten

orangetw commented 3 years ago

@orangetw Thank you so much for writing A10 and your feedback. Here my answeres ;-)

Log all accepted and blocked network flows (see A09:2021-Security Logging and Monitoring Failures). Establish an ownership and a lifecycle for firewall rules based on applications

As this section is about "How to Prevent", I am not sure the logging and monitoring fit to this section.

Outdated firewall rules could be used with SSRF to access services that were out of scope when deploying a new service. Logging all accepted and blocked network flow on firewalls could help to detect SSRF (by A-09). I suggested to add it, as it might not immediately obvious. Infrastructure and applications should work here together.

I agree with you, but since this is more like suggestions instead of preventions. Maybe we can put them in a new block? For example:

How to Prevent: -> From Network layer -> From Application layer -> Nice-to-Have or Recommendation (I don't have an idea of the name now)

Don't deploy other security relevant services on front systems. Control local traffic on these systems (e.g. localhost)

Is there any different between the Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic and this?

Here I've had in mind to protect that services on localhost could be attached by SSRF (additionally to other servers)

I still don't get the point, could you explain more about the scenario? Did you mean the case uses the proxy (such as the Security Gateway) to protect the system from SSRF?

For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independant systems to consider very high protection needs

I don't understand why VPN can prevent the system from SSRF

If you have a B2B application or Remote Access for your employees this might not reduce SSRF itself but the attack vector about who is able to attack your applications througt SSRF.

Maybe this can be also put in the Nice-to-Have block, too?

Thanks!

sslHello commented 3 years ago

Reordered and improved the commit while discussing with @orangetw. Thank you for your review.