目前我正在如下定义内容安全策略 (CSP)；
Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
考虑到上面的 CSP 定义，我对内联 JavaScript 有一个挑战，因为它可以随时被覆盖。
如果unsafe-inline 实际上无法提供保护，它有什么用？
【问题讨论】：
标签： security content-security-policy
unsafe-inline 选项用于在当前站点中移动或重写内联代码不是一个直接的选项，但您仍希望使用 CSP 来控制其他方面（例如 object-src，防止注入第三个-派对js等）。你是对的，unsafe-inline 没有提供太多安全性，因为它允许执行不安全的页内脚本和事件处理程序。
Google 的 CSP Evaluator 是一个很好的工具，可以确定您的政策是否有效。
使用unsafe-inline 选项的用例可以在 Google 的Web Developer documentation on Content Security Policy 中找到：
婚戒论坛管理员希望确保所有资源仅通过安全渠道加载，但实际上并没有编写太多代码；重写大量充满内联脚本和样式的第三方论坛软件超出了他的能力。以下政策将是有效的：
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'即使在
default-src中指定了https:，脚本和样式指令也不会自动继承该源。每个指令都会完全覆盖该特定类型资源的默认值。
【讨论】：
虽然我同意它并不能提供太多保护，但 XSS 的经典利用是浏览器利用框架，您在 Internet 上有一个服务器，当您遇到 XSS 漏洞时，您会在“http://bad. example.com/hook.js"> 现在您可以从该服务器控制受害者的浏览器。你告诉它打开一个隐藏的窗口来保持访问，然后你就可以双向通信到他们的浏览器。
具有“不安全内联”的 CSP 仍然可能允许所有相同的利用（假设利用适合您可以注入的空间），但连接到外部世界以接收指令或泄露数据的难度稍大一些.
也就是说，如果您可以将足够复杂的客户端部分注入网页，我认为仍然可以通过其他渠道进行大多数相同的攻击。
在“self unsafe-inline”上使用我的攻击者帽子比完全没有 CSP 更难利用。我希望攻击工具能够适应较弱的 CSP，但这意味着很多常见的漏洞利用会立即失效，或者更难。
【讨论】：