什么是最大允许的内容安全策略？ [英] What is the maximally permissive Content-Security-Policy?

问题描述

我有一个大型的旧代码库，我想在其上引入 Content-Security-Policy 标头。在短期内完全锁定站点是不可行的（例如，到处都是内联脚本，没有自动测试覆盖率），但至少我可以从禁止访问我知道的内容源开始确保当前未使用它，然后随着时间的推移逐渐降低它的使用率。

I have a large, legacy codebase that I'd like to introduce the Content-Security-Policy header on. It is not feasible in the short term to truly lock-down the site (for example, there are inline scripts all over the place that have no automated test coverage), but at least I can start by forbidding access to content sources that I know for sure aren't in use currently and then slowly ratchet it down over time.

不幸的是，未使用的源列表很短。这是我第一次尝试使用 Content-Security-Policy 值：

Unfortunately, the list of sources that aren't being used is rather short. This was my first attempt at a Content-Security-Policy value:

default-src * 'unsafe-eval' 'unsafe-inline'

这打破了很多东西，例如使用data：scheme 来源的图像。环顾四周，我看到您可能想包含的许多内容，例如 connect-src ws：，在文档。

That broke a number of things, such as images sourced using the data: scheme. Looking around, I see a number of things you might want to include, such as connect-src ws:, that aren't explicitly called out in the docs.

最大允许的 Content-Security-Policy 标头值是多少基本上可以让网站执行默认情况下允许浏览器执行的所有操作？问另一种方式：我可以引入什么标头值肯定不会破坏网站上的任何内容？

What is the maximally permissive Content-Security-Policy header value that basically lets the site do everything the browser is allowed to do by default? Asked another way: what header value can I introduce that definitely won't break anything on the site?

我会更舒适地引入如果我可以从我知道不会破坏任何内容的开头开始，则将其插入旧站点，然后减去我知道可以安全删除的权限。

I'd feel more comfortable introducing the header into the legacy site if I could start with something that I know won't break anything, then subtract out the permissions that I know are safe to remove.

推荐答案

tl; dr使用仅报告模式向旧站点引入策略。

请参见w3.org/TR/CSP2/#source-list-guid-matching。

See w3.org/TR/CSP2/#source-list-guid-matching.

如上定义，特殊的URL方案引用特定的
独特内容，例如 data：， blob：和 filesystem：被排除在匹配策略*之外的
，必须明确列出。

As defined above, special URL schemes that refer to specific pieces of unique content, such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and must be explicitly listed.

因此，类似于 default-src *'unsafe-eval''unsafe-inline''unsafe-dynamic'数据：文件系统：关于：blob：ws：wss：可能接近最宽松的政策。当然，还有更多的协议可能需要列入白名单。

Therefor, something along the lines of default-src * 'unsafe-eval' 'unsafe-inline' 'unsafe-dynamic' data: filesystem: about: blob: ws: wss: is probably close to the most lenient policy. There are more protocols that may need to be whitelisted, of course.

如何

通常人们采取相反的方法。他们将使用 Content-Security-Policy-Report-Only部署标头：default-src'none'不会影响网站的加载，并且可以使您棘手根据违规或控制台警告下调策略。

Typically people take the opposite approach. They will deploy the header with Content-Security-Policy-Report-Only: default-src 'none' which will not affect the loading of your site and will allow you to ratchet down your policy based on the violations or console warnings.

我强烈建议您从 caspr chrome扩展以创建初始策略，然后使用report-uri.io查看违规情况。当您的策略看起来很稳定并且违规最少时，请将策略切换为强制模式。

I highly recommend you start with the caspr chrome extension to create an initial policy and then use report-uri.io to view report violations. When your policy seems stable and violations are minimal, then switch your policy to enforce mode.

这篇关于什么是最大允许的内容安全策略？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！