XSS Payload 可以绕过特殊字符检查。

huangapple go评论75阅读模式
英文:

XSS Payload That Can Bypass Special Character Check

问题

我开发了以下的C#算法来防止XSS攻击:

private bool Is_There_XSS_Payload(string arg)
{
    Regex regex = new Regex(@"^[a-zA-Z0-9]+$");
    bool result = regex.IsMatch(arg);
    return result;
}

如果参数arg包含任何非字母数字字符,它会返回false,并且不会继续处理该参数。

这里的问题是,是否有任何XSS负载可以绕过这个算法?我是否需要一个数据编码算法,还是仅仅这个验证就足以防止XSS攻击?

英文:

I developed the following C# algorithm to prevent XSS attacks:

private bool Is_There_XSS_Payload(string arg)

{
    
   Regex regex = new Regex(@"^[a-zA-Z0-9]+$");
    
   bool result = regex.IsMatch(arg);
    
   return result;
    
 }

If the arg parameter contains any non-alphanumeric character, it returns false and does not make progress with the parameter.

Here the question is, can any XSS payload bypass this algorithm? Do I need a data encoding algorithm, or is only this validation enough to prevent XSS attacks?

答案1

得分: 1

跨站脚本攻击基本上是一个输出编码问题,除了一些非常特殊的情况外,几乎不可能通过输入过滤在实际应用中完全防止。

由于您的过滤器非常严格(例如,甚至不允许空格),如果您可以将其应用于所有输入,我看不出如何执行任何有意义的XSS攻击。但是对于任何实际应用程序,这个过滤器都不会起作用,通常您需要至少一些其他字符,这时问题就出现了。即使没有其他字符,也可以在特殊情况下用来引用已经存在的函数等。

另外,这个过滤器将应用于什么地方呢?用户输入不仅仅是GET参数和POST正文。您会将其应用于Cookie值吗?这肯定会破坏许多现有的(框架或第三方)代码,比如身份验证或CSRF保护。但如果不应用于Cookie或请求头,那么您如何确保Cookie值或请求头在输出中不会被任何使用?比如在未来的3年里,即使是您,更不用说其他开发人员,都会忘记这个?

然后,DOM XSS怎么办,其中服务器端过滤甚至都不参与比赛,因为所有的攻击都纯粹是利用Javascript?服务器端的任何过滤对此都是无用的,只有在客户端代码中进行适当的编码才有帮助。

总之,理论上这样的过滤器可以防止大多数XSS攻击(尽管在引用现有代码可能导致漏洞的特殊情况下,甚至这也不成立)。但真正的问题是,对于大多数应用程序来说,这个过滤器在实际中不太实用,并且完全忽略了DOM XSS。

任何试图防止XSS的输入过滤解决方案几乎肯定会在某种程度上存在缺陷,一个有技巧和资源的攻击者会找到绕过它的方法。只有通过上下文感知的输出编码(即在所有正确的地方应用正确的编码)才能安全地防止XSS。

英文:

Cross-site scripting is fundamentally an output encoding problem, and it is (almost) impossible to prevent via input filtering in a real application, except some very special cases.

As your filter is very strict (not even allowing whitespace for example), sure, if you can apply this to ALL input, I can't see how any meaningful XSS could be performed. But this filter will not work for any real-world application, you will need at least some other characters in general, and there your problems already start. Even without other characters, this could be used to reference already existing functions in special cases and so on.

Also, what would this be applied to? User input is not just GET parameters and POST body. Would you apply this to cookie values too? That will surely break a lot of existing (framework or 3rd party) code like authentication or CSRF protection. But if not applied to cookies or request headers, how will you ensure that cookie values or request headers are not ever used in output? Like 3 years in the future, when even you, let alone other devs will have forgotten this?

And then what about DOM XSS, where server-side filtering doesn't even join the game, as all of the attack purely exploits Javascript? Any filtering on the server-side is useless for that, only proper encoding in the client-side code helps.

So to sum it up, sure, in theory such a filter would prevent most XSS (though not even that is true in special cases where referencing existing code might lead to vulnerabilities). But the real problem is that this filter is not practical for most applications, and it completely disregards DOM XSS.

Any input filtering solution attempt to XSS will almost certainly be flawed in some way, and a skilled and resourceful attacker will find ways to get around it. XSS can only be securely prevented by context-aware output encoding (ie. applying the right encoding at all the right places).

huangapple
  • 本文由 发表于 2023年8月4日 20:51:03
  • 转载请务必保留本文链接:https://go.coder-hub.com/76836086.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定