提问人：KosD 提问时间：8/4/2023 更新时间：8/6/2023 访问量：721
可以绕过特殊字符检查的 XSS 有效负载
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 攻击？
答：
1赞
Gabor Lengyel
8/6/2023
#1
跨站点脚本从根本上说是一个输出编码问题，除了一些非常特殊的情况外，在实际应用程序中（几乎）不可能通过输入过滤来防止。
由于您的过滤器非常严格（例如，甚至不允许空格），当然，如果您可以将此应用于所有输入，我看不出如何执行任何有意义的 XSS。但是这个过滤器不适用于任何实际的应用程序，你至少需要一些其他角色，你的问题已经开始了。即使没有其他字符，这也可用于在特殊情况下引用已经存在的函数，依此类推。
另外，这将适用于什么？用户输入不仅仅是 GET 参数和 POST 正文。你也会把它应用于cookie值吗？这肯定会破坏许多现有的（框架或第三方）代码，如身份验证或 CSRF 保护。但是，如果不应用于 cookie 或请求标头，您将如何确保 cookie 值或请求标头永远不会在输出中使用？就像未来 3 年一样，什么时候连你，更不用说其他开发者了，都会忘记这一点？
那么 DOM XSS 呢，服务器端过滤甚至没有加入游戏，因为所有的攻击都纯粹利用了 Javascript？服务器端的任何过滤都是无用的，只有客户端代码中的正确编码才有帮助。
总而言之，当然，从理论上讲，这样的过滤器可以防止大多数 XSS（尽管在引用现有代码可能导致漏洞的特殊情况下甚至不是这样）。但真正的问题是，这个过滤器对于大多数应用程序来说并不实用，它完全忽略了 DOM XSS。
几乎可以肯定的是，任何对 XSS 的输入过滤解决方案尝试都会在某种程度上存在缺陷，熟练且足智多谋的攻击者会找到绕过它的方法。XSS 只能通过上下文感知输出编码（即在所有正确的位置应用正确的编码）来安全地防止。
评论