CVV #2: Open Redirect
This is a short series about “Common Vulnerability Vectors” and related exploitation-methods.
If you didn’t read my first post (CVV #1) about Local-File-Inclusion, here you go! Today it’s all about Open Redirects (short: “OR”).
According to the OWASP-Project an open redirect is a kind of vulnerability defined in the following way:
[…] when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials […]
Let’s look at a simple example of an web-application written in PHP which is vulnerable to “OR”:
header('Location: ' . $_GET['url']);
die(); // this is sometimes missing which can leads to an authentication bypass
After submitting the following HTTP-request:
GET vulnerable.php?url=https://si9int.sh HTTP/1.1
We should get a server-side redirect (HTTP 301; HTTP 307) to our URL defined via the url-Parameter.
The following content describes methods based on my current knowledge who might be useful when exploiting “OR” issues by e.g. expanding to Cross-Site-Scripting.
Thanks to: bobrov, filedescriptor,cujanovic, securityidiots for contributing their knowledge to this topic.
 Bypassing keyword filtering
If a domain filters for a specific keyword (mostly the domain-name itself) it is possible to bypass this by e.g. using the keyword as a part of the injected domain (subdomain or n’th-lvl-domain).
GET vulnerable.php?url=victim.com.attacker.com HTTP/1.1
A successful exploitation can be also obtained via using a “@” sign. Browsers will redirect anything after the AT_SIGN to the specified domain (thanks to the login-URI schema included in most modern browsers; Try it).
GET firstname.lastname@example.org HTTP/1.1
The third way is creating a folder named like the vulnerable domain on your own server and using it as payload in hope that the vulnerable script will ignore the first/n‘th part of the URL.
GET vulnerable.php?url=attacker.com/victim.com HTTP/1.1
This can be also useful when the application requires a specific extension in-path. In this case we may create a folder named like the required extension and pass it to the vulnerable parameter.
GET vulnerable.php?url=attacker.com/.jpg HTTP/1.1
 Bypassing blacklisted keywords
There might be applications who are already filtering the vulnerable parameter for certain keywords and therefore not redirecting if some of the blacklisted keywords are set as value. Here is a list on how to bypass these keywords:
- a.) Most filters can be bypassed by using a double-URL or triple-URL encoded version of the blacklisted char/keyword
- b.) Dots e.g.
https://attacker%E3%80%82com, ( 。, URL-encoded), a Chinese separator which browsers handling the same way as dots
- c.) HTTP- or HTTPS-keyword e.g.
//attacker.com, two slashes are enough for a browser to recognize the use of the HTTP/HTTPS protocol
- d.) Slashes e.g.
https:attacker.com, auto-correction of modern browsers leads to this behavior
- e.) Slashes and HTTP/HTTPS-keywords, bypass:
\/\/attacker.com, same reason as above
I hope you learned some new things. If you found any content-related or grammatical errors or have an addition, write a comment.