Open Redirect
Vulnerability Overview
Open Redirect (CWE-601) is a vulnerability that occurs when a user-controlled input is used to construct a link to an external site, and the application uses that link in an HTTP redirect. This simplifies phishing attacks.
The flaw commonly occurs when the application sets the Location HTTP response header with an unsafe value from the HTTP request. In other words, the HTTP redirect URI can be controlled by the attacker.
Recommended Security Controls
According to the OWASP and MITRE recommendations, to be protected against Open Redirect, applications must:
-
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e. use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
-
If user input cannot be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
The most common scenario of an open redirect attack is when the attacker redirects the user to an external, malicious, domain.
How Waratek’s Protection Works
Waratek offers protection against Open Redirect attacks via the redirect declaration in the ARMR HTTP rule. This rule uses the tainting engine to track all user input, hooks into the Servlet API and monitors server-side HTTP redirect operations. When an HTTP redirect operation occurs, the Waratek agent deems the redirect unsafe if both the location URI is user-controllable (tainted) and if it is external to the application's domain. Tainted redirect locations to external root domains are not allowed. The rule detects or protects against HTTP server-side redirects to an external root domain, different subdomain or IP address from the application's.
For example, if the redirect rule is enabled and assuming that the application is hosted on the domain “www.example.com” then user-controlled server-side HTTP redirects to the following domains will be deemed malicious and blocked: “www.google.com” , “www.example.co.uk” , “test.example.com”, “test1.test2.example.com”.
If the application depends on user-controlled HTTP redirects to different subdomains of the same root domain, then the open-redirect(options: {exclude: subdomains}) option must be configured in the rule. Only user-controlled HTTP redirects to different root domains will be considered malicious by the rule.
For example, if the exclude=subdomains option is enabled and assuming that the application is hosted on the domain “www.example.com” then user-controlled server-side HTTP redirects to the following domains will be deemed malicious and blocked: “www.google.com” , “www.example.co.uk”. Note that user-controlled server-side HTTP redirects to the following domains will be deemed safe and allowed: “test.example.com”, “test1.test2.example.com”.
By default, when no taint source is specified in the rule, the open redirect rule protects against attacks coming from HTTP requests. Users have the option to also enable protection against open redirect attacks coming from other sources such as relational databases and/or deserialization-based protocols such as RMI.
Protective Action
When the Open Redirect rule is enabled in protect mode and an Open Redirect attack is identified then the malicious HTTP redirect operation is terminated.
Rule Applicability
The Open Redirect rule is applicable and can be safely enabled for web applications that:
-
Use the Servlet API to handle HTTP requests and responses.
-
Perform server-side HTTP redirects to URLs of the same domain or a subdomain of the application’s root domain.
Applications that by design allow users to set the redirect location to external root domains are not supported by the open redirect rule.
The Open Redirect rule does not protect against client-side open redirect vulnerabilities, such as the ones performed on the browser by Javascript.
Best Practices
Waratek recommends not to enable the Open Redirect rule in blocking mode if the application depends on user-controlled server-side HTTP redirect operations to external domains. Consider enabling the rule in detect mode to monitor the server-side HTTP redirect behavior of the application and keep track of external redirects.
References
https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html