文章使用google翻译
原文：https://blog.innerht.ml/the-misunderstood-x-xss-protection/
被误解的X-XSS-Protection
前几天，我在Twitter上进行了一次民意调查，看看人们认为是XSS过滤器/审核员最糟糕的环境。结果是非常惊人的：
Which header setting of XSS filter/auditor do youthink is the worst?
— File Descriptor (@filedescriptor) March 17, 2017
总之，最糟糕的是X-XSS-Protection: 0，其次X-XSS-Protection: 1; mode=block，最后X-XSS-Protection: 1是最坏的。在我看来（也可能是其他一些人），结果是令人惊讶的，因为我们期望他们是相反的（即X-XSS-Protection: 1应该是最差的）。在这篇简短的博客文章中，我将讨论这些问题，并希望让人们认识到安全性的含义。简单的介绍
在Internet Explorer 8中，引入了针对XSS攻击的防御。这种浏览器内置的功能称为XSS过滤器，旨在缓解反映的XSS。Webkit后来有了自己的版本，叫做Chrome和Safari的XSS审计。这个想法很简单：如果一个恶意的输入被反映在文档中，反射的部分将被删除或整个文档根本不会被渲染。
关于设置，网站可以明确地包含X-XSS-Protection标题，告诉浏览器过滤器/审核员应该如何操作。Thare有三种可能的选择：
- 0（禁用XSS过滤器/审核员）
- 1（删除不安全的部分;如果没有X-XSS-Protection标题，这是默认设置）
- 1; mode = block（如果找到XSS，则不要渲染文档）
让我们来谈谈离开设置默认的问题。第一个问题是它扩大了攻击面。通过滥用误报，攻击者可以选择性地禁用页面上的无辜脚本。
XSS审计员在行动
在上面的例子中，jQuery库尽管不应该被删除。这是因为审计人员无法区分脚本是被攻击者注入的还是用于页面的。你可以想象，如果这是一个安全库，攻击者可以简单地伪造一个注入并将其移除。事实上，类似的技巧已经被用来对付基于JS的frame-buster。
第二个问题是它引入了新的漏洞。在2009年，由于XSS滤波器的缺陷，在IE中发现了UXSS。实质上，攻击者可以将无害的标记变成有害的标记，因为过滤器错误地替换了关键位置中的字符，从而损坏了原始文档结构。通过精心制作的有效载荷，可以为属性上下文提供转义。最近，还有更多UXSS被发现在其他上下文中使用与XSS过滤器完全相同的根本原因。
第三个问题是XSS过滤器/审计员旁路是不可避免的。你可以看看这个，这个，这个和这个。从历史中学习，我们知道无论过滤器/审核员如何努力改进，总会有潜在的绕过。此外，审计师在某些情况下也有其自身的局限性。Chromium团队实际上清楚地表明，XSS审计师只是一种纵深防御机制，并不能抓住所有可能的XSS变体。
所以现在应该不会有人认为XSS过滤器/审核员很容易被绕开，而其部分移除方法是有问题的。那么“全部或全部”的方法（也X-XSS-Protection: 1; mode=block就是最推荐和最普通的方法）是救世主吗？
乍看之下，似乎可以解决误报滥用的问题，并且在删除脚本的过程中消除引入漏洞的可能性，同时提供最小的防御。它肯定能防止攻击者滥用误报，但不幸的是，它不断引入新的漏洞。其中最重要的一个是引发Facebook 泄密的引用漏洞。这也是为什么Facebook决定关闭XSS过滤器/审计员（即）。其他相关的错误包括这个和这个。与上面相比，虽然bug数量相对要小得多。X-XSS-Protection: 0
那么，最佳选择？
总而言之，这取决于X-XSS-Protection: 0和之间的情况X-XSS-Protection: 1; mode=block。如果您认为您的应用程序无XSS或无法承担不寻常的筛选器/审计器错误，那么请选择前者。否则，一般使用后者是完美的。经验法则是你永远不会默认它。