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.
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
I was thinking to use directory traversal method to have my target domain in the URL and also point to the vulnerable page:
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:
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!
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:
However, this only works in Firefox and I have to use encoding for IE and Google Chrome:
Job done! Success!
Now I can redirect the user to my dangerous page and hijack the secrets in any browsers!
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.