CSP style-src: 'unsafe-inline' - 值得吗？

Question

目前我在我的所有网站上都使用 Modernizr，事实证明，由于它的工作方式，它需要允许unsafe-inline样式。 我已经不允许内联脚本和脚本的 unsafe-eval 了。 好奇允许内联样式存在哪些安全风险？

Answer 1

允许内联样式使您容易受到“其他 XSS”的影响。 跨站点样式攻击。

这里的想法是，用户可以在您的文档中注入样式属性的任何地方，他们都可以按照他们想要的方式修改页面的外观。 我将列出几个按严重程度排序的潜在攻击：

1. 他们可以把你的页面变成粉红色，让它看起来很傻。
2. 他们可以修改您页面的文本，使您看起来像是在说一些冒犯性的话，可能会冒犯您的读者群。
3. 他们可以使用户生成的内容（例如他们提供的链接）出现在人们期望看到用户内容的正常位置之外，使其看起来是官方的。 （例如，用他们自己的链接替换您网站上的“登录”按钮）。
4. 使用精心设计的样式规则，他们可以将页面上包含的任何信息发送到外部域，并恶意公开或以其他方式使用这些数据来攻击您的用户。

第四个示例，尽管存在unsafe-inline ，但可以完全防止信息泄露到外部域，前提是您确保您的其他 CSP 规则永远不允许任何类型的请求进入不受信任或通配符域。 但是如果您错过在某处阻止样式属性，前 3 个总是可能的。

几年前， Mike West为 CSSConf 做了一个很好的 演讲，提供了更多的例子。

Answer 2

就我个人而言，我发现不对 CSS 使用 unsafe-inline 是不切实际的。 这意味着我必须为每种样式使用外部样式表文件。 着色文本，居中文本等。它可以做到。 您可以通过使用主样式表“main.css”和每个页面的文件表（“index.css”、“contect.css”等）来做到这一点。 但是，我并没有那么愚蠢，以至于允许任意代码执行； 我过滤掉所有更少的东西，然后擦掉所有的迹象。 我认为这是一个不合理的限制。 阻止内联 JavaScript 并不像阻止内联 CSS 那样糟糕。 我可以看到阻塞内联 JavaScript。 但是我不认为我会那样做。 如果你小心地过滤你的 less then 和 grater then 符号（除了不过滤这些之外，你还可以做一些其他愚蠢的事情）如果你不犯允许任意代码执行的愚蠢错误，那么你是安全的。 创建这些内联块只是为了保护以允许任意代码执行的方式搞砸代码的 Web 开发人员。 但是这些块使编码变得有点困难。 所以这是一个权衡。

TLDR 恕我直言，不值得阻止内联 CSS，值得阻止内联 JavaScript，但没有必要。 我不会考虑阻止内联 CSS，我不会阻止内联 JavaScript，但我可能会考虑。

经验：我是一名网页设计师，使用 HTML CSS JavaScript 和 PHP 进行代码设计。 我有自己的网站，我手工编码。 我使用官方的 w3 验证器进行验证。 我跟上 HTML5 等网页设计标准。