XSS - 内容安全策略

Question

通过将内容安全策略设置为default-src'self'，可以100％防止XSS？在这种情况下，XSS有什么办法可以发生吗？我能想到的一种可能性是在服务器端动态地将用户输入注入到您的一个脚本中，您同意吗？您还能想到其他任何漏洞吗？

Answer 1

不，CSP不是一个神奇的子弹。它应该是一道防线，而不是整个防线。如果配置正确，可以提供帮助

• 阻止可用的XSS，其中有效负载（无论是持久的还是反射的）必须很小，因此通常只会创建一个脚本元素并注入外部代码
• 避免数据提取和滥用作为攻击其他网站的平台。根据应用程序的工作方式，访问后端服务可能足以提取数据，例如，如果您的用户可以撰写博客文章，攻击者可以使用需要提取的数据创建新帖子，等待数据发出信号已被抓取（例如通过评论）并再次删除帖子，所有这些都没有与外部服务器通信。

Answer 2

要回答这个问题，是的default-src 'self'现代浏览器仍然可以执行用户控制的javascript：JSONP。

  

特别值得注意的是我们的源列表中缺少self。而   从self采购JavaScript似乎相对安全（而且非常   常见的），应该尽可能避免。

     

任何开发人员都必须关注边缘情况   当允许self作为脚本的源时。可能有一个被遗忘的   没有清理回调函数名称的JSONP端点。

来自http://githubengineering.com/githubs-csp-journey/

Answer 3

不应将CSP用作防止XSS攻击的唯一方法。此机制仅适用于客户端（如果将恶意数据保存到数据库中，则可能会开始感染与其集成的其他系统），并且所有浏览器都未实现（http://caniuse.com/#search=csp）。

要防止XSS，您应始终验证输入数据并对输出数据进行编码。您还可以在JavaScript控制台中打印警告消息，以防止以某种方式自我XSS攻击（例如打开Facebook页面并打开Chrome开发人员工具 - 查看控制台中的消息）。

请记住，网站上的用户输入不是XSS的唯一来源。恶意数据也可能来自：

1. 从文件导入数据
2. 从第三方系统导入数据
3. 从旧系统迁移数据。
4. Cookie和http标头。

如果您有适当的数据验证和编码（服务器端），那么您还可以应用浏览器机制，例如：CSP，X-XSS-Protection或X-Content-Type-Options，以增加您对系统安全的信心