Constructing a server-side redirect path with user input could allow an attacker to download application binaries -(including application classes or jar files) or view arbitrary files within protected directories.
+Directly incorporating user input into a URL forward request without validating the input +can cause file information disclosure by allowing an attacker to access unauthorized URLs.
Unsanitized user provided data must not be used to construct the path for URL forwarding. In order to prevent
-untrusted URL forwarding, it is recommended to avoid concatenating user input directly into the forwarding URL.
-Instead, user input should be checked against allowed (e.g., must come within user_content/
) or disallowed
-(e.g. must not come within /internal
) paths, ensuring that neither path traversal using ../
-or URL encoding are used to evade these checks.
-
To guard against untrusted URL forwarding, it is advisable to avoid putting user input +directly into a forwarded URL. Instead, maintain a list of authorized +URLs on the server; then choose from that list based on the user input provided.
The following examples show the bad case and the good case respectively.
-The bad
methods show an HTTP request parameter being used directly in a URL forward
-without validating the input, which may cause file leakage. In the good1
method,
-ordinary forwarding requests are shown, which will not cause file leakage.
+
The following example shows an HTTP request parameter being used directly in a URL forward +without validating the input, which may cause file information disclosure. +It also shows how to remedy the problem by validating the user input against a known fixed string.
The following examples show an HTTP request parameter or request path being used directly in a -request dispatcher of Java EE without validating the input, which allows sensitive file exposure -attacks. It also shows how to remedy the problem by validating the user input. -
- -The following examples show an HTTP request parameter or request path being used directly to -retrieve a resource of a Java EE application without validating the input, which allows sensitive -file exposure attacks. It also shows how to remedy the problem by validating the user input. -
- -The following examples show an HTTP request parameter being used directly to retrieve a resource - of a Java Spring application without validating the input, which allows sensitive file exposure - attacks. It also shows how to remedy the problem by validating the user input. -
- -