zoukankan      html  css  js  c++  java
  • 安全隐患,你对X-XSS-Protection头部字段理解可能有误

    *本文原创作者:bgusko63190,本文属FreeBuf原创奖励计划,未经许可禁止转载

    0×00. 引言
    我曾做过一个调查,看看网友们对关于X-XSS-Protection 字段的设置中,哪一个设置是最差的,调查结果令我非常吃惊,故有此文。

    网友们认为 最差的配置是X-XSS-Protection: 0,其次是 X-XSS-Protection: 1; mode=block, 反而X-XSS-Protection: 1 成了不是最差的配置了。在我看来(其他人也可能和我持有同样观点),X-XSS-Protection: 1 应该是最差的配置。

    在这篇文章中,我会和大家一起讨论有关X-XSS-Protection的配置,最后希望大家明白什么样的X-XSS-Protection配置才是有安全隐患的。

    0×01. 科普下相关知识
    从IE8 开始,IE 浏览器内置了一个针对XSS攻击的防护机制,这个浏览器内置的防护机制就是所谓的XSS filter,这个防护机制主要用于减轻反射型XSS 攻击带来的危害。 基于Webkit 内核的浏览器(比如Chrome)随后也增加一个名为XSS auditor 的防护机制,作用和IE中的XSS filter类似。这两种XSS防护机制的目的都很简单,如果浏览器检测到了含有恶意代码的输入被呈现在HTML文档中,那么这段呈现的恶意代码要么被删除,要么被转义,恶意代码不会被正常的渲染出来,当然了,浏览器是否要拦截这段恶意代码取决于浏览器的XSS防护设置。

    至于怎么设置浏览器的XSS防护机制,其实很简单,只要在HTTP响应报文的头部增加一个X-XSS-Protection 字段,明确地告诉浏览器XSS filter/auditor该如何工作。 X-XSS-Protection 的字段有三个可选配置值

    0: 表示关闭浏览器的XSS防护机制

    1:删除检测到的恶意代码, 如果响应报文中没有看到X-XSS-Protection 字段,那么浏览器就认为X-XSS-Protection配置为1,这是浏览器的默认设置

    1; mode=block:如果检测到恶意代码,在不渲染恶意代码

    0×02. X-XSS-Protection的默认配置并不安全
    让我们一起讨论一下浏览器中关于X-XSS-Protection字段的默认设置。 其实默认设置有安全隐患的。

    第一个安全隐患就是:
    默认设置扩大了攻击面, 比如攻击者可以利用这个默认设置选择性的删除页面中某些脚本,下图就是一个例子

    XSS-auditor-in-action.png

    在上图的例子中, jQuery 库竟然被意外的删除了,之所以会出现这样的现象,是因为 浏览器的XSS auditor分不清jQuery库是页面本身自带的还是攻击者注入的。 如果这次被以外删除的是一个和安全相关的js库,你可以想象,攻击者注入一个和含有js安全库名字的恶意代码,这样就可以把这个js安全库给删除了。 类似这样的攻击手法已经出现了,点击这里查看详情

    第二个安全隐患是:
    默认设置会引入新的漏洞,早在2009年,IE浏览器就因为XSS filter的缺陷被爆出一个UXSS漏洞。实际上,攻击者可以将无害的标签变成有害的标签,因为过滤器有时候很傻,会不正确地替换了关键位置的字符,从而损害了原始文档的结构。

    通过精心制作的有效载荷,可以绕过属性下文的限制。 最近,我发现很多类似UXSS的漏洞被发现,这些漏洞本质上的原因都是一样的。

    第三个安全隐患:
    必然会有绕过XSS filter/auditor 的方法出现, 不信你可以看看以前被绕过的例子,比如这个, 这个, 这个, 还有这个。 从这些被绕过的案例中,我们可以发现,不管XSS filter/auditor 的过滤多么严格, 它总存在被绕过的可能, 此外,XSS filter/auditor 在某些场景下是有短板的,Chromium 小组曾经很明确的表明:XSS auditor 只是众深防御的一环,完全靠它是无法防止所有的XSS攻击。

    好了。至此,大家对XSS filter/auditor 是可以被绕过的这一观点没有异议吧。 XSS filter/auditor的默认设置会部分删除它认为的恶意代码,这种做法有时候是有问题的,所以XSS-Protection: 1; mode=block这个设置是最好的了喽?

    咋一看,好像是没了上述提到的问题,而且还能提供一定的防御能力,可不幸的是,这样的配置还是会引入新的漏洞, 最明显的一个例子就是 Refer 泄露的BUG,这个漏洞导致了Facebook账户劫持漏洞. 这也是Facebook 为什么选择禁用XSS filter/auditor的原因。引入的漏洞不仅仅这一个,其他的漏洞比如这个, 还有这个。 当然了,和上述提到的漏洞相比,这种配置引入的漏洞还是相对少一点。

    0×03. 那么问题来了,最好的设置是什么
    总而言之, 至于设置成XSS-Protection: 0还是XSS-Protection: 1; mode=block取决于你的业务场景,如果在你的业务场景中,你认为你的程序或系统是不会有XSS漏洞的, 或者是无法承担XSS filter/auditor 特性引发的BUG,那你就选择配置成前者;否则,你还是选择配置成后者吧。 反正,老司机给你一句忠告就是,千万别配置成XSS-Protection: 1

    *本文原创作者:bgusko63190,本文属FreeBuf原创奖励计划,未经许可禁止转载

    更多精彩 # X-XSS-Protection

  • 相关阅读:
    mysql函数
    maven 配置自动本地/线上不同配置自动打包
    maven clean后 编译报错
    htmlunit填坑
    java正则表达式移除网页中注释代码
    spark 计算结果写入mysql 案例及常见问题解决
    pychrome激活
    hadoop集群常见问题解决
    hadoop+spark集群搭建
    C++:构造函数2——拷贝构造函数
  • 原文地址:https://www.cnblogs.com/suizhikuo/p/12215256.html
Copyright © 2011-2022 走看看