【问题标题】:Why is inline script forbidden (Content Security Policy)?为什么禁止内联脚本(内容安全策略)?
【发布时间】:2013-04-03 07:06:02
【问题描述】:

我想知道规范中的引用: (https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html)

为了获得最大的好处,作者需要将所有内联脚本和样式移到外部脚本中,例如移到外部脚本中,因为用户代理无法确定内联脚本是否被攻击者注入。

找出所有内联脚本是一项耗时的任务。

我的问题是从安全的角度来看的。通过将所有内联脚本(例如 JavaScript)提取到外部源,您真的可以获得任何安全优势吗?

谢谢

【问题讨论】:

  • 请注意,CSP 1.1 计划提供允许您将单个脚本块列入白名单的功能。 (通过脚本随机数或脚本哈希)。这仍然是一条出路,删除内联脚本仍然是您最万无一失的路线。

标签: javascript inline content-security-policy


【解决方案1】:

关键部分是

用户代理无法确定内联脚本是否被攻击者注入。

为了提供保护,CSP 必须防止攻击者控制的子字符串导致代码运行。由于用户代理不知道 HTML 的哪些部分是由不受信任的输入指定的,哪些来自受信任的开发人员编写的模板,因此它必须假设最坏的情况——任何属性或元素都可能被攻击者控制。

通过将所有内联脚本(例如 JavaScript)提取到外部源,您真的可以获得任何安全优势吗?

没有。提取您要运行的脚本不会提供任何安全优势,它只是让您在仍然使用 CSP 的同时运行所需的脚本。

安全优势在于能够调用浏览器的 HTML 解析器,而不会无意执行滥用域权限或窃取机密的脚本。

【讨论】:

  • 删除所有内联脚本确实可以保证您永远不会将动态内容放在脚本标签中(这通常会导致不良行为)。 。这是否是一个安全利益是相当有争议的:)
  • @oreoshake,一般情况下同意“删除所有内联脚本”,但与内容安全警察一起使用时不同意,其中policy.allowsInlineScript 是假的,这是 OP 所暗示的。
猜你喜欢
  • 2021-08-21
  • 2017-09-07
  • 2019-04-06
  • 2020-12-16
  • 1970-01-01
  • 2021-03-25
  • 1970-01-01
  • 2019-01-19
  • 2012-01-20
相关资源
最近更新 更多