Open Redirect vulnerabilities are possible when a web application accepts untrusted input to redirect the user to a new arbitrary (external) website. Without proper validation, malicious actors can leverage this flaw by surreptitiously redirecting victims to malware or phishing sites or forwarding them to unauthorised pages.
This attack was featured on the OWASP Top 10 list web application security risks for many years, and although it has been dropped in the most recent iteration, it remains an important risk to mitigate, as it can be used as the genesis of a chain of escalating attacks.
Open Redirect can be used by malicious actors to carry out phishing attacks by redirecting the user to a malicious site and stealing user credentials. Unless users are extremely observant, it’s very likely they won’t notice the redirection to a different domain, especially if the attacker has taken pains to ensure the forged page precisely mimics the legitimate login page.
Additionally, Open Redirect may facilitate other types of attacks such as:
Cross Site Scripting: an XSS vulnerability may be introduced if the user’s browser supports
- Server Side Request Forgery: SSRF filters can be evaded with open redirects
Whether it be a small scale scam, or a much larger compromise that result from an Open Redirect opening the door, developers have a responsibility to ensure they maintain high web application security standards by choosing best security standard functions.
The following exemplifies what is possible when an attacker is able to redirect the browser to a malicious site using a trustworthy-looking domain name to gain the victim’s trust.
The following snippet of code suffers from Open Redirect vulnerability:
string url = request.QueryString["url"]; Response.Redirect(url);
Which can be exploited by an attacker that crafts the following URL:
If inserted in a convincing enough phishing attempt, an unwitting user may only pay attention to the domain name and click on the link, not realising he or she is redirected to the malicious website
The most obvious solution to this issue is to cease the use of redirects that depend on user-provided input. Of course, sometimes this is not possible for sites that require this facility in order to function properly.
In cases where user input absolutely cannot be avoided, developers must ensure that the supplied value is mapped to an actual value (rather than the actual URL) and that the server-side code translates this value to the target URL. This approach allows for the maintenance of a permitted redirection URL allow list.
If the redirect is local to the application, ensure that the URL used for redirection is a relative URL.
Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.
- OWASP ASVS: 5.1.5