Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages Unvalidated Redirects and Forwards.
Applications frequently redirect users to other pages or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.
Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder because they target internal pages.
Attacker links to unvalidated redirect and tricks victims into clicking it. Victims are more likely to click on it since the link is to a valid site. Attacker targets unsafe forward to bypass security checks.
Such redirects may attempt to install malware or trick victims into disclosing passwords or other sensitive information. Unsafe forwards may allow access control bypass.
The application has a page called “redirect.php” which takes a single parameter named “URL”. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware.
The application uses forward to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts an URL that will pass the application’s access control check and then forward the attacker to an administrative function that she would not normally be able to access.
How to Detect
The best way to find out if an application has any unvalidated redirects or forwards is to:
- Review the code for all uses of redirect or forward (called a transfer in .NET). For each use, identify if the target URL is included in any parameter values. If so, if the target URL isn’t validated against a whitelist, you are vulnerable.
- Also, spider the site to see if it generates any redirects (HTTP response codes 300-307, typically 302). Look at the parameters supplied prior to the redirect to see if they appear to be a target URL or a piece of such an URL. If so, change the URL target and observe whether the site redirects to the new target.
- If the code is unavailable, check all parameters to see if they look like part of a redirect or forward URL destination and test those that do.
How to Mitigate
Safe use of redirects and forwards can be done in a number of ways:
- Simply avoid using redirects and forwards.
- If used, don’t involve user parameters in calculating the destination. This can usually be done.
- If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translates this mapping to the target URL.
Applications can use ESAPI to override the sendRedirect()method to make sure all redirect destinations are safe.
Avoiding such flaws is extremely important as they are a favorite target of phishers trying to gain the user’s trust.