How can an open redirect web vulnerability be exploited?
An open redirection happens when a web application or server uses an unvalidated user-submitted link to redirect the user to a given website or page. Even though it seems like a harmless action to let users decide where they want to be redirected, if exploited with malicious intent, this technique can have a serious impact on application security, especially when combined with other vulnerabilities and tricks.
Abusing user trust in the vulnerable website
Since the domain name in a URL is typically the only indicator for a user to recognize a legitimate website from a non-legitimate one, an attacker can abuse this trust to exploit an open redirect vulnerability on the vulnerable website and redirect the user to a malicious site to execute further attacks, as explained in the following sections.
Exploiting an open redirect vulnerability for a phishing attack
When a user clicks on a link of a legitimate website they often won’t be suspicious if suddenly a login prompt shows up. To launch a successful phishing scam, the attacker sends the victim a link, for example via email, which exploits the vulnerability on the vulnerable website example.com:
By exploiting the open redirect vulnerability on the legitimate website using the URL parameter value, the attacker is redirecting the victim to http://attacker.com/phish. This is a phishing page with a trustworthy appearance that is similar to the original site. Once the visitor is on the attacker’s malicious website, they enter their credentials on the login form, which points to a script that is controlled by the attacker. The script is typically used to steal user credentials that are being typed in by the victim and save them server-side. Attackers typically use them at a later stage to impersonate the victim on the legitimate web page.
The probability of successful phishing attempts is quite high since the server name example.com is shown when the user clicks on the link.
Exploiting an open redirect vulnerability to redirect victims to malicious websites
It is also possible to redirect an otherwise careful web user to a site hosting attacker-controlled content, like a browser exploit or a page executing a CSRF attack. As above, the chances that the victim clicks the link are higher if the site that the link points to is trusted by the victim. An example is an open redirect in a trustworthy page like a banking site that directs the victim to a page with a CSRF exploit against a vulnerable WordPress plugin.
Exploiting an open redirection vulnerability to execute code
An open redirection vulnerability in a web application can also be used to execute an XSS payload by redirecting to
location header with
Another URI scheme that’s useful to an attacker is
data:. While this does not work in Webkit-based Browsers like Google Chrome or Opera anymore, in Mozilla Firefox the attacker can still redirect to it. What this does is write data directly to the browser window, which could ease the process of creating phishing pages, even without using a web server to host them.
What is the impact of an open redirection vulnerability?
As mentioned above, the impacts can be many, and vary from the theft of information and credentials to the redirection to malicious websites containing attacker-controlled content, which in some cases even cause XSS attacks. So even though an open redirection might sound harmless at first, the impacts of it can be severe should it be exploitable.
How can you prevent open redirection vulnerabilities?
The easiest and most effective way to prevent vulnerable open redirects would be to not let the user control where your page redirects them to. If you have to redirect the user based on URLs, instead of using untrusted input you should always use an ID which is internally resolved to the respective URL. If you want the user to be able to issue redirects you should use a redirection page that requires the user to click on the link instead of just redirecting them. You should also check that the URL begins with
https:// and also invalidate all other URLs to prevent the use of malicious schemes such as
Vulnerability classification and severity table
|Classification||ID / Severity|