From 04476ca5f4a64d2348d82d5579e7c7d8ac5bd166 Mon Sep 17 00:00:00 2001 From: Kevin Stubbings Date: Tue, 25 Feb 2025 00:16:48 -0800 Subject: [PATCH] Add more choices to SSRF remediation --- .../CWE-918/ServerSideRequestForgery-end.inc.qhelp | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/python/ql/src/Security/CWE-918/ServerSideRequestForgery-end.inc.qhelp b/python/ql/src/Security/CWE-918/ServerSideRequestForgery-end.inc.qhelp index 2259680e9f8e..c40fe1d5711e 100644 --- a/python/ql/src/Security/CWE-918/ServerSideRequestForgery-end.inc.qhelp +++ b/python/ql/src/Security/CWE-918/ServerSideRequestForgery-end.inc.qhelp @@ -5,8 +5,11 @@

To guard against SSRF attacks you should avoid putting user-provided input directly - into a request URL. Instead, either maintain a list of authorized URLs on the server and choose - from that list based on the input provided, or perform proper validation of the input. + into a request URL. On the application level, maintain a list of authorized URLs on the server and choose + from that list based on the input provided. If that is not possible, one should verify the IP address for all user-controlled + requests to ensure they are not private. This requires saving the verified IP address of each domain, + then utilizing a custom HTTP adapter to ensure that future requests to that domain use the verified IP address. + On the network level, you can segment the vulnerable application into its own LAN or block access to specific devices.