ModSecurity 针对 XSS 类型 0 攻击和影响的防护

发布于 2024-10-06 17:53:25 字数 327 浏览 3 评论 0原文

基于 DOM(类型 0)的 XSS 不需要向服务器发送恶意代码,因此它们也可以使用静态 HTML 页面作为攻击媒介。这里的虚拟攻击字符串的示例如下:

http://www.xssed.edu/home.html#<script>alert("XSS")</script> 

我很熟悉 ModSecurity 提供针对 PDF 中的 XSS 攻击的保护,这些攻击被视为类型 0 攻击,但是我的问题是 ModSecurity 是否通常可以防止这种类型的 XSS 攻击,并且在 PDF 中也可以防止这种类型的 XSS 攻击。您认为此类漏洞会产生什么影响。

DOM-based (type 0) XSS do not require sending malicious code to the server and thus they can also use static HTML pages as an attack vector. An example of a dummy attack string here would be the following:

http://www.xssed.edu/home.html#<script>alert("XSS")</script> 

I am familiar that ModSecurity offers protection against XSS attacks in PDFs which are considered type 0 attacks, however my question is if ModSecurity does in general prevent against this type of XSS and also in your opinion what are the impacts of such a vulnerability.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夢归不見 2024-10-13 17:53:25

每个 Web 应用程序防火墙都使用攻击签名来工作。 0 型 XSS 生成与反射 XSS 相同的签名,因此任何 WAF 都可能阻止这种情况。由于服务器站点代码漏洞,不会发生 Type-0 XSS,但请求显然是在页面加载过程中到达服务器的。
唯一可以阻止 WAF 阻止此类攻击的问题是文件的扩展名,但我相信在您的示例中这可能会被阻止。

Every web application firewall is working using signatures of attacks. Type-0 XSS generates the same signature as reflected XSS so this would probably be stopped by any WAF. Type-0 XSS does not occur due to server site code vulnerability but the request obviously reaches the server in the process of the page loading.
The only issue that could prevent the WAF from stopping this kind of attack is the extension of the file, but I believe that in your example this would probably be stopped.

蓦然回首 2024-10-13 17:53:25

如果您重写规则主体,这实际上是可能的。
让我们举两个例子,eval 和innerHTML sink,它们容易受到DOM XSS 的攻击。我们所要做的就是重写输出的主体。

 SecRule REQUEST_URI "/sitestoprotect/" "chain,phase:4,t:none,t:urlDecode,t:lowercase,t:normalizePath"
    SecRule STREAM_OUTPUT_BODY "@rsub s/innerHTML/textContent/" "chain"
    SecRule STREAM_OUTPUT_BODY "@rsub s/var load/var msg = JSON.parse(e.data);var load"

It is actually possible if you were to rewrite the body of the rules.
Lets take two example, eval and innerHTML sink which are vulnerable to DOM XSS. All we have to do is the rewrite the body of the output.

 SecRule REQUEST_URI "/sitestoprotect/" "chain,phase:4,t:none,t:urlDecode,t:lowercase,t:normalizePath"
    SecRule STREAM_OUTPUT_BODY "@rsub s/innerHTML/textContent/" "chain"
    SecRule STREAM_OUTPUT_BODY "@rsub s/var load/var msg = JSON.parse(e.data);var load"
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文