Open Redirect
The Open Redirect is a vulnerability that occurs when a developer does not verify that the redirect URL is one of its own or a trusted 3rd party. To a hacker, this means that they can silently navigate a user off of the page if there are no "interstitial redirect popups or warning splash pages. With this they can send innocent looking links or phish that look to be of a trusted domain (before the redirect).
Things to look for:
2 GET requests generated by a single link or URL
URL params (url, u, r, redirect, next, link, ..)
Can you inject <meta> tags or edit them
Can you modify the DOM location property
Redirect GET requests:
Keep and eye out for 3XX response codes and for redirect params in proxy history. Then see if you are getting a second GET request being generated from the single URL or Link that you crawled (not invoked by a JS call). If so then this is a good candidate for an open redirect. Check to see if the second location is being referenced in the link/url and if so; can it be modified to leave the site? The best scenario would be a redirect where yo get redirected off the site and you do net get a pop up warning.
This same investigation and attack works with the <meta> refresh HTML tag and the DOM Location window property. All 3 of these can generate the 3XX redirects you can leverage.
Examples of such vulnerabilities can look like:
URL/Link based:
In this following case we have a link/URL based redirect where we can replace gmail.com with our attacker domain. If the server allows us to do this we have an Open Redirect vuln.
https://www.google.com/?redirect_to=https://www.gmail.com
Meta based:
The following is an example of what it can look like in an HTML <meta> tag. The same concept applies.
<meta http-equiv="refresh" content="0; url=https://www.google.com/">
Here, once the meta tag is rendered the browser starts a counter and in this case waits 0 seconds before then requesting the google.com link in the content parameter.
DOM based:
The window location DOM property can be controlled either through JS or by the site allowing us to specify our own location values as a feature. To leverage the JS option we typically will have to be leveraging a XSS vuln and chaining these together for impact. The following are examples of how those javascript calls could be made.
Impact:
Get the user on to your own site where you have scripts waiting to do your dirty work. Once you are finished it would be best to send them back to the intended link location for the least amount of "oddity" in the end-user's eyes.🙈 🙉
Prevention:
When a redirect occurs, the server first determines where to send your browser and if the destination site is up. If it is, the site will typically return a 302 to the browser with the location to navigate to via a GET. Its this check that the application and server are doing that should also include a verification to ensure the redirect destination has not been tampered with or is a trusted location within your organizations spec.
Although typically 302's these redirects can also be 301, 303, 307, or 308's
Last updated