JavaScript的客户端DOM开放重定向 [英] Client DOM Open Redirect for javascript

问题描述

我在扫描以下代码时遇到客户端DOM开放重定向安全性问题.问题出现在我要初始化变量"myPath"和"myHost"的位置.

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;
}

推荐答案

问题是您正在接受用户输入(URL栏中的值)并重定向到该输入.这可能会或可能不会在任何有意义的攻击中加以利用，但是静态扫描仪无法理解您的应用程序逻辑-对于静态扫描仪，仅用户输入将直接在重定向中使用.

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.

根据问题中的信息，我无法想到有效的攻击，因为我认为它只是使用户访问过的URL相同，最后没有.html，并且如果没有#部分，有.因此，我认为用户将被重定向到他已经访问过的页面.但是，这完全不意味着没有漏洞，它还取决于其他相关代码.例如，当用户可以使用此代码访问页面而网址栏中没有任何.html时，会影响结果，而另一个漏洞(允许(部分)控制网址栏)也会受到影响，这可能是SPA之类的情况.因此，问题中没有足够的信息来确定它是否真正安全.

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.

对于此修复程序，请确保仅将您重定向到想要的位置，而不重定向到任何用户输入.例如，主机部分(甚至是路径)可以由服务器写在页面中，但是我知道对于SPA之类的情况并非如此.您可以实施白名单验证，以确保不会发生恶意重定向.也许已经很不错了，在这种情况下，您可以将所发现的内容设置为在使用的扫描仪中缓解，但请考虑一下极端情况，以及攻击者如何滥用这种情况.他可以在路径中用#欺骗吗?他可以从没有.html的url加载带有此代码的页面吗?还是有多次?如果他注册了someattack.html.hisdomain.com之类的域名并有有效的用户访问该怎么办?:)

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? :)

URL栏是一件棘手的事情，因为它是用户输入，但是攻击者没有完全控制权-他必须访问应用程序页面，否则将不会加载此javascript.仍然是由静态扫描程序标记的原因是，攻击者可能具有 some 控件，并且在使用大量javascript的单页应用程序的情况下，由于所有的url栏操作仍在进行，因此可能还要多一些

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.

这篇关于JavaScript的客户端DOM开放重定向的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！