1

据我了解，我需要在标头服务器端禁用 X-XSS-Protection 以防止通过 GET 请求发生 XSS。

例如，用户浏览到

http://mysite.com/index.php?page=<script type='text/javascript'> alert("XSS"); </script>

假设 $_GET['page'] 从 PHP 回显到页面而没有以任何方式改变，XSS 审核员应该捕捉到来自请求的内容被回显到页面并停止它。

这是否足以防止 XSS 攻击，或者攻击者可以绕过这种浏览器保护？

充分意味着它被所有主要浏览器支持并且不可绕过。

4

3 回答 3

2

一点都不。客户端 XSS 过滤试图在客户端解决服务器端问题（缺少输出转义），但没有足够的知识来解决问题。它永远无法 100% 工作，并且总是会产生误报。这是一项纵深防御措施，也是一个非常值得怀疑的措施。您不能单独依赖它作为 XSS 的解决方案。

客户端 XSS 过滤：

  • 无法防御多重反射 XSS（即包含<在一个参数script中和另一个参数中，后者在其旁边获得输出）；

  • 无法防御特定于应用程序的编码层（例如以 JSON 格式提交、解码和显示而不转义）；

  • 不能防御表单参数以外的输入类型；

  • 无法防御基于在页面中插入脚本以外的其他内容的攻击；

  • 在防御诸如 CSS 之类的晦涩的脚本注入方式方面有着非常不完整的历史；

  • 根本无法防御存储的 XSS；

  • 并非所有流行的浏览器都支持；

  • 允许攻击者有选择地禁用您页面上的脚本，从而破坏它。

这不是一场胜利。

于 2013-07-23T11:07:23.430 回答
1

捕获反射型 XSS 攻击可能就足够了，但它无法阻止更有害的持续性XSS 攻击。此外，并非所有浏览器都有 XSS 保护。您真的只希望某些用户仅因为您忽略了转义输出而获得保护吗？在适当的地方转义将修复这两种类型的 XSS，即使浏览器缺乏 XSS 保护。

于 2013-07-23T03:31:56.583 回答
1

我不建议根据用户的浏览器进行任何类型的保护，因为浏览器的版本和类型总是不可预测的。这意味着您需要确保在服务器/应用程序级别采取所有措施来防止 XSS（或任何其他类型的攻击）。

于 2013-07-23T02:07:02.077 回答