HOW OPEN REDIRECTS WORK
Open redirects occur when a developer mistrusts attacker- controlled input to redirect to another site, usually via a URL parameter, HTML <meta> refresh tags, or the DOM window location property.
Many websites intentionally redirect users to other sites by placing a destination URL as a parameter in an original URL. The application uses this parameter to tell the browser to send a GET request to the destination URL. For example, suppose Google had the functionality to redirect users to Gmail by visiting the following URL:
https://www.google.com/?redirect_to=https://www.gmail.com
In this scenario, when you visit this URL, Google receives a GET HTTP request and uses the redirect_to parameter’s value to determine where to redirect your browser. After doing so, Google servers return an HTTP response with a status code instructing the browser to redirect the user. Typically, the status code is 302, but in some cases it could be 301, 303, 307,
.
or 308. These HTTP response codes tell your browser that a page has been found; however, the code also informs the browser to make a GET request to the redirect_to parameter’s value, https://www.gmail.com/, which is denoted in the HTTP response’s Location header. The Location header specifies where to redirect GET requests.
Now, suppose an attacker changed the original URL to the following:
https://www.google.com/?redirect_to=https://www.attacker.com
If Google isn’t validating that the redirect_to parameter is for one of its own legitimate sites where it intends to send visitors, an attacker could substitute the parameter with their own URL. As a result, an HTTP response could instruct your browser to make a GET request to https://www.<attacker>.com/. After the attacker has you on their malicious site, they could carry out other attacks.
When looking for these vulnerabilities, keep an eye out for URL parameters that include certain names, such as url=, redirect=, next=, and so on, which might denote URLs that users will be redirected to. Also keep in mind that redirect parameters might not always be obviously named; parameters will vary from site to site or even within a site. In some cases, parameters might be labeled with just single characters, such as r= or u=.
In addition to parameter-based attacks, HTML <meta> tags and JavaScript can redirect browsers. HTML <meta> tags can tell browsers to refresh a web page and make a GET request to
.
a URL defined in the tag’s content attribute. Here is what one might look like:
<meta http-equiv=”refresh” content=”0; url=https://www.google.com/”>
The content attribute defines how browsers make an HTTP request in two ways. First, the content attribute defines how long the browser waits before making the HTTP request to the URL; in this case, 0 seconds. Secondly, the content attribute specifies the URL parameter in the website the browser makes the GET request to; in this case, https://www.google.com. Attackers can use this redirect behavior in situations where they have the ability to control the content attribute of a <meta> tag or to inject their own tag via some other vulnerability.
An attacker can also use JavaScript to redirect users by modifying the window’s location property through the Document Object Model (DOM). The DOM is an API for HTML and XML documents that allows developers to modify the structure, style, and content of a web page. Because the location property denotes where a request should be redirected to, browsers will immediately interpret this JavaScript and redirect to the specified URL. An attacker can modify the window’s location property by using any of the following JavaScript:
window.location = https://www.google.com/ window.location.href = https://www.google.com window.location.replace(https://www.google.com)
Typically, opportunities to set the window.location value occur only where an attacker can execute JavaScript, either via a
