http-headers - 内容安全策略 - 值得吗？

Question

我正在考虑在多个站点上实现 CSP。

如果我不这样做有什么风险？

问题的原因是实现 CSP 有其自身的风险 - 不必要地阻止某些操作系统的浏览器，每次都必须包含新添加的外部资源等。

这值得么？

Answer 1

CSP 是一个非常有用且可能非常简单的工具。我强烈建议每个人都实现它，即使一些不太理想的设置，如 unsafe-inline必须使用。

风险

CSP 中的唯一风险是维护 CSP 列表，因此，如果您未能维护该列表，可能会意外阻塞资源。

由于 CSP，旧浏览器不会丢失功能。与大多数现代 Web 技术一样，CSP 是一种“渐进式增强”，如果您在不支持 CSP 的古老浏览器上甚至使用极其严格和现代的 CSP 访问网站，唯一的结果将是完全忽略 CSP。旧浏览器会做与阻止访问者完全相反的事情；他们将被允许访问任何内容，就好像 CSP 根本不存在一样(因为，就浏览器而言，它并不存在)。

困难

实现 CSP 的难度完全取决于您的设置以及您想要的挑剔程度。如果您的站点完全来自单一来源并且不使用第三方代码，您可以在 5 分钟内启动并运行一个限制最大但功能齐全的 CSP。

第三方和遗留代码的数量是需要多长时间的主要因素。您的网站的来源和内联样式/脚本越多，它就会变得越复杂和令人沮丧。但这也是重构的好机会。

一些值得注意的流行代码库可能对 CSP 很挑剔，它们是 Wordpress(许多带有内联脚本/样式的顽皮插件和主题)和 Google Adsense(几乎不可能知道脚本将从哪里加载并且 unsafe-inline 基本上是必需的)。

好处

XSS(跨站点脚本)保护

在这一点上，CSP 保护的不仅仅是传统的 XSS，但它增加了一种方法，让客户端浏览器准确地知道什么是允许的，什么是不允许的。例如，如果用户在试图插入比特币挖掘 javascript 文件的恶意公共(public) wifi 网络上加载您的站点，您可以拒绝它。当然，CSP 应该与强制 HTTPS 配对以确保

它甚至可以保护您(部分)免受恶意浏览器扩展的侵害(当然，如果客户端的 PC 在访问您之前已经受到损害，您的 CSP 来保存它们就太迟了)。即使您的页面以某种方式被更改，某些注入(inject)恶意软件的脚本也将拒绝加载。

CSP当然是一种安全策略，所以安全性是主要的好处。它的特别之处在于，它允许根据您的喜好进行严格或宽松的精细控制，阻止或允许框架、字体、脚本、样式等全部分开，大到允许所有内容，小到只允许来自一个文件的单个文件。源而不是信任整个域。

促进良好做法

CSP 最大的问题是非常讨厌、挑剔的第三方代码。不安全的内联样式和 eval() 的东西出 wazoo，从 8 个不同源服务器上的 10 个不同文件加载，所有文件都具有不可发音的不可描述的名称。

虽然将所有这些糟糕的事情列入白名单很烦人，但通过提出实际问题，CSP 应该有助于鼓励第三方清理他们坦率地说令人讨厌、不安全和性能不佳的代码。当然，这需要一段时间(尽管 Google 在大多数网络方面具有前瞻性，但由于 Adsense 和 Adwords 使用其脚本处理区域的方式，Google 是最严重的违规者之一)。

CSP 将帮助您意识到从一致的来源为您的所有内容提供服务是多么有值(value)，甚至可能向第三方供应商投诉，这些供应商通过 30 次额外请求加载图像文件和一些文本来破坏您的网站。

举报

实际上，了解您的站点在野外而不是在受控测试环境中会发生什么可能会很痛苦，但使用 report-uri (或很快， report-to )您实际上可以收到有关用户自己看到的 CSP 违规行为的报告。当您的 CDN 或脚本“有帮助地”向不同用户提供不同资源时，这会有所帮助。

执行

我强烈建议您使用 Mozilla Observatory 测试您的设备检查您的一般安全 header 并发现问题，谷歌 Chrome 浏览器的浏览器工具特别擅长报告 CSP 违规(如果需要，甚至可以为资源提供 SHA 哈希)。