An open redirect vulnerability occurs when a victim visits a particular URL for a given website and that website instructs the victim’s browser to visit a completely different URL, on a separate domain. For example, suppose Google had utilized the following URL to redirect users to Gmail:
https://www.google.com?redirect_to=https://www.gmail.com
Visiting this URL, Google would receive a GET HTTP request and use the redirect_to parameter’s value to determine where the visitor’s browser should be redirected. After doing so, Google would return a 302 HTTP response, instructing the user’s browser to to make a GET request to https://www.gmail.com, the redirect_to parameter’s value. Now, suppose we changed the original URL to:
https://www.google.com?redirect_to=https://www.attacker.com
If Google wasn’t validating that the redirect_to parameter was for one of their own le- gitimate sites where they intended to send visitors (https://www.gmail.com in our example), this could be vulnerable to an open redirect and return a HTTP response instructing the visitor’s browser to make a GET request to https://www.attacker.com.
The Open Web Application Security Project (OWASP), which is a community dedicated to application security that curates a list of the most critical security flaws in web applications, has listed this vulnerability in their 2013 Top Ten vulnerabilities list. Open redirects exploit the trust of a given domain, https://www.google.com/ in our example, to lure victims to a malicious website. This can be used in phishing attacks to trick users into believing they are submitting information to the trusted site, when their valuable information is actually going to a malicious site. This also enables attackers to distribute malware from the malicious site or steal OAuth tokens (a topic we cover in a later chapter).
When searching for these types of vulnerabilities, you’re looking for a GET request sent to the site you’re testing, with a parameter specifying a URL to redirect to.
Reviews
There are no reviews yet.