Web applications often 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 use unauthorized pages.
Sometime, your application may need to redirect to another area by sending a redirect header to the customer in an HTTP response.This method found in applications that divert after an successful verification.
The redirection will be in the login form or the URL. both of which can be messed with by the client.Such redirects may attempt to install malware or trick victims into revealing passwords or other delicate data. Risky forwards may permit get to control bypass.
Developers can prevent the weakness by approving client input and furthermore confirming the URL being referred to is really an endorsed target URL.
You can use a guide map technique where URLs are mapped to names, for example, landing page, item pages, or stock page. This would keep clients from providing an invalid URL.
How to check for invalidated Redirects and Forwards?
- 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 seem to be a target URL or a piece of such a URL. If so, change the URL target and see whether the site redirects to the new target.
- Check the code for all users of redirect or forward (called a move in .NET). For every use, distinguish if the objective URL is incorporated into any parameter values. Provided that this is true, if the objective URL isn’t approved against a white list, you are vulnerable.
- If 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 Test?
This vulnerability occurs when an application accepts untrusted input that has an URL value without sanitizing it.
This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials.
Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
A phishing attack example could be the following:
http://www.testdomain.com?#redirect=www.fake-target.site
If the application uses forwards 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 a URL that will pass the application’s access control check and then forwards the attacker to administrative functionality for which the attacker isn’t authorized.
http://www.example.com/boring.jsp?fwd=admin.jsp
Impact on Website
• Lack of End User Trust
• Lack of Credibility
• Malware Installation
• Worm Infections
Common Defences
- Destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user.
- Simply avoid using redirects and forwards.
Reference: https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards
Also Read:
- A1 – SQL injection
- A2 – Broken Authentication and Session Management
- A3 – Cross Site Scripting
- A4 – Insecure Direct Object References
- A5 – Security Misconfiguration
- A6 – Sensitive Data Exposure
- A7 – Missing Function Level Access Control
- A8 – Cross-Site Request Forgery (CSRF)
- A9 – Using Components with known Vulnerabilities
