Chrome 终于要放弃 XSSAuditor 了 ​​​​

avatar 2019年7月17日08:43:00Chrome 终于要放弃 XSSAuditor 了 ​​​​已关闭评论

Chrome 终于要放弃XSSAuditor了,原因有几个:引用
1.还是会存在大量饶过;
2.不断的对抗反而因为误报导致一些正常网页显示有问题,且可能带来新的安全风险;

我的观点

1.支持废弃XSSAuditor;
2.XSS缓解应该让Web服务方自己解决,由于好的Web开发框架越来越成熟与安全,对抗XSS已经不是个难事;
3.浏览器的CSP安全策略很棒,实践好也是对抗的好方式;
4.Cookie 安全里的HttpOnly机制用好,也能做点缓解(阻止身份Cookies被JavaScript抓取)。

 

工作中,用Selenium自动化填表并获取结果时,程序一直安静的读取数据库,网页填表,获取结果,存库,但跑着跑着突然报错了。引用

排查后,原来不是Selenium的问题,是数据比较特殊,带了个双引号

填表后提交时,触发了Chrome XSS自动过滤器  xssAuditor,导致POST请求拦截。(文尾会延伸:Chrome xssAuditor的工作原理

Chrome提示如下错误:

然后查了下解决办法,能否关闭 xssAuditor,非WIN10下个人认为最好的解决办法如下:

但WIN10没法按此办法解决,只能放弃Chrome浏览器 ,声明浏览器改火狐(browser = webdriver.Firefox() ),换用火狐后,它没有自动过滤的情况 【成功解决】

延伸部分:

Chrome xssAuditor的工作原理:

chrome的xss检测名称为 xssAuditor  整合到webkit当中,chrome这么做的原因是因为过滤器可以在脚本执行之前就可以拦截,而且任何使用webkit都可以使用这些规则

当加载网页时,xssAuditor会在渲染的之前评估用户的输入数据:

1.检查用户输入是否包含恶意内容,如果存在进行拦截

2.xssAuditor检测用户是否会反射到渲染的页面中(html实体/html熟悉/javascript/css/url)

3.评估输入上下文是否合法,非法进行过滤

chrome的检测机理和ie还有很大的区别是,chrome是在此法解析阶段进行的,讲html解析不同的token(类似php vld opcode),xssAuditor会逐一扫描检测token,

如果token中发现危险的属性和URL进行比较,如果URL中也存在同样的数据,xssAuditor则会认为这是一个反射XSS。

demo:

解析器解析<iframe src="x" onerror="alert(1)"></iframe>

1.依次检查标签iframe是否包含恶意属性,src/onerror

2.如果src不是以javascript:开头,则安全,放行

3.onerror中含有脚本,检查URL是否包含

4.如果出现在URL中,认为存在安全问题,将过滤 <iframe src="x" onerror="void(0)"></iframe>

5.中止iframe标签检查

avatar