CVV #2: Open Redirect

This is a short series about “Common Vulnerability Vectors” and related exploitation-methods.

Low-hanging fruits are easier to collect

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= 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.

[1] Execute JavaScript

It is possible to execute JS by using an “OR” vulnerability thanks to the javascript-URI and data-URI wrapper. This can be achieved by redirecting to the specified wrapper (beware that this works only when the application did the redirect client-side by e.g. injecting an anchor-tag into the current DOM).

GET vulnerable.php?url=javascript:alert(1) HTTP/1.1
GET vulnerable.php?url=data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTs8L3NjcmlwdD4NCg== HTTP/1.1

[2] 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? 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 vulnerable.php? 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? 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? HTTP/1.1

[3] 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. , bypass: 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. , bypass: // , two slashes are enough for a browser to recognize the use of the HTTP/HTTPS protocol
  • d.) Slashes e.g. , bypass: , auto-correction of modern browsers leads to this behavior
  • e.) Slashes and HTTP/HTTPS-keywords, bypass: \/\/ , 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.