JavaScript的客户端DOM开放重定向

Question

I'm getting Client DOM Open Redirect security issue on scan for the following piece of code. The issue shows up where I'm initializing the variables 'myPath' and 'myHost'.

I'm not able to understand how is that open to phising attack and how do I fix it. Could anyone please help?

var query = this.value;

var myPath = window.location.href.substring(window.location.href.indexOf("/myapp"), window.location.href.indexOf(".html"));
var myHost = window.location.href.substring(0, window.location.href.indexOf("/myapp"));
query = encodeURIComponent(query);

if(myPath!==null){
    query = query + "mysite:" + myHost + myPath;
}

Answer 1

The problem is that you are taking user input (values from the url bar) and you redirect to it. This may or may not be exploitable in any meaningful attack, but static scanners don't understand your application logic - for a static scanner it's just user input that will directly be used in a redirect.

Based on the info in the question, I can't think of a valid attack, because I think it just makes the same url that the user already visited, without .html in the end, and also without the # part if there was any. So I think the user will be redirected to a page that he visited already. However, that doesn't at all mean there is no vulnerability, and it also depends on other related code. What happens when the user can access a page with this code without any .html in the url bar would for example affect the outcome, so would another vulnerability that allows (partial) control of the url bar, a possible scenario for something like an SPA. So there is not enough info in the question to decide whether it's actually secure or not.

As for the fix, make sure you only redirect where you want to, and not to any user input. For example the host part (maybe even the path) could be written in the page by the server, but I understand that would not be the case for something like an SPA. You could implement whitelist validation to ensure no rogue redirects happen. Maybe it's already good, in which case you can set this finding to mitigated in the scanner you used, but think about edge cases, and how this can be abused by an attacker. Can he trick this with # in the path? Can he load a page with this code from an url that doesn't have .html? Or has it multiple times? What if he registers a domain like someattack.html.hisdomain.com and has a valid user visit it? :)

The url bar is a tricky thing, because it's user input, but the attacker doesn't have full control - he must hit an application page, otherwise this javascript won't be loaded. Still the reason this is flagged by a static scanner is because an attacker may have some control, and in case of javascript-heavy single page applications, probably a bit more because of all the url bar manipulation going on.