如何利用X-XSS-Protection进行恶意攻击

两个可以缓解XSS攻击的重要响应头是：

X-XSS-Protection
Content-Security-Policy

那么它们有什么区别呢？

像Internet Explorer和Chrome这样的浏览器包含一个"XSS审计器"，它试图帮助防止反射型XSS攻击的执行。第一个响应头控制在浏览器中的这个功能。

详细说明在这里，但基本上支持的四个选项是：

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=

需要注意的是，除非用户（或其管理员）禁用了它，否则审计器默认是激活的。

因此，X-XSS-Protection: 1将为用户重新启用它。

第二个响应头Content Security Policy是一个较新的头部，它控制HTML页面可以从哪里加载其内容，包括JavaScript。基本上，除了unsafe-inline之外的任何指令都意味着注入到页面中的JavaScript将不会执行，并且可以缓解反射型和存储型XSS。CSP是一个比我在这里要涵盖的更广泛的话题，但是，关于该头的详细信息可以在这里找到。

我想向你展示的是指定block与完全不包含该头（因此将采用浏览器中的设置）或指定1而不带block之间的区别。此外，为了更好的说明，我还将展示Content Security Policy对跨站脚本的缓解措施。

我将向你展示一种方式，如果站点指定了X-XSS-Protection而没有block，如何滥用这一点。

链接页面包含以下代码：

1
2
3


<script>document.write("one potato")</script><br />
<script>document.write("two potato")</script><br />
three potato

现在，如果我们直接从你正在阅读的当前页面链接到那里，两个脚本块应该会执行：

正常链接

为了演示XSS审计器的工作原理，让我们想象一下我们尝试通过附加这个查询字符串来注入该脚本到页面中：

1

?xss1=<script>document.write("one potato")</script>&xss2=<script>document.write("two potato")</script>

请注意，以下内容在Firefox中不起作用，因为在撰写本文时，Firefox不包含任何XSS审计器，因此如果访问的站点存在漏洞，它非常容易受到反射型XSS的攻击。如果Firefox是你选择的浏览器，你可以使用noscript附加组件来保护自己。请注意，以下内容仅在Chrome 64中进行了测试。我还将通过向输出添加X-XSS-Protection: 1来在支持的浏览器中启用你的XSS过滤器。

注入链接

请注意浏览器现在如何认为两个脚本块已被注入，因此阻止它们并仅输出纯HTML。如果你不相信代码仍然存在，请查看源代码。

查看F12开发者工具显示审计器已经完成了它的工作：

查看源代码显示哪个脚本被阻止（红色）：

现在攻击者可以做什么来滥用XSS审计器？他们可以操纵页面以阻止他们选择的脚本。

1

?xss2=<script>document.write("two potato")</script>

被滥用的链接

查看源代码显示攻击者只是通过在URL中指定源代码来阻止了他们想要的内容：

当然，编辑他们自己的链接是徒劳的，他们必须通过电子邮件、Facebook、Skype等方式将链接传递给他们的受害者。

这有什么风险？《Web应用程序黑客手册》比我说的更好：

那么我们如何防御这一点？嗯，你猜对了，就是block指令：

1

X-XSS-Protection: 1; mode=block

让我们用这个指定再试一次：

启用block模式的被滥用链接

因此，通过指定block，我们可以防止攻击者制作链接来中和我们现有的脚本！

总之，指定block总是好的，因为默认情况下XSS审计器只尝试阻止它们认为正在被注入的内容，这可能实际上并不是恶意脚本本身。

那么Content Security Policy呢？

只是为了演示区别，如果我们输出一个防止内联脚本的CSP头并且不尝试注入任何内容：

CSP示例

Chrome向我们显示这完全是由于Content Security Policy：

作为站点开发者，要解决这个问题，我们可以按照CSP中的描述指定SHA-256哈希，或者只要我们在策略中白名单self，就可以简单地将代码移动到单独的.js文件中。任何注入内联脚本的攻击者都将被阻止。当然，Content Security Policy的问题在于它似乎仍然是一个事后想法，并且尝试制定一个适合现有站点的策略非常困难，除非你的站点几乎是静态的。然而，如果做得正确，它是一个很好的缓解措施。不过，策略中的任何弱点都可能被利用。希望如果我将来在任何参与中遇到它，我会有一篇关于这个的文章。

*是的，你没有使用X-XSS-Protection来做坏事，但当然缺少block，如果没有人弄乱浏览器设置，就好像已经输出了X-XSS-Protection: 1。

利用X-XSS-Protection头进行恶意攻击的技术解析

本文深入分析了X-XSS-Protection头的四种配置方式及其安全影响，通过实际案例演示了攻击者如何利用未启用block模式的配置来绕过防护，并对比了Content-Security-Policy的防护机制。

如何利用X-XSS-Protection进行恶意攻击