部署CSP:五步走法— DareBoost博客

您可能已经看过Dareboost的建议,以就资源的来源制定安全策略。 如果您还没有参与,请根据我的经验为它的实施提供一些建议。

在此已经解释过的想法很简单:为浏览器定义安全准则,以使其适用于页面内容。 实际上,此标头非常强大,并且提供了很多可能性。

但是,实施CSP可能会令人恐惧,因为这是一件相当复杂的事情。 作为多年来一直对此主题感兴趣的有说服力的从业者,我想与您分享一种基于我自己的经验的实施方法。 但是首先,让我们将其放到上下文中。

CSP不是二进制开关

通常将安全性视为交换机。 网站是否安全。
这种对安全性的二元看法是完全错误的。 :安全性是一个过程,因此,可以根据您的上下文,历史记录,需求,预算等确定不同的等级。CSP也不例外。 您经常会听到由于CSP的原因,您需要在前端“束紧腰带”:就像拳击手根据自己想参加的比赛类别调整自己的体重一样,您的CSP实施会更多根据您的安全需求限制较少。 高度敏感的站点将不需要与展示站点相同类型的安全性。

在考虑部署CSP时要评估的另一个重要点: 您对前端的掌握程度如何?
当我们谈论掌握前端时,我们并不需要证明该团队是有天赋的CSS还是由JavaScript组成的……而是要了解在客户端发生的事情。

换句话说,您对内容来源(脚本,CSS,Web字体,第三方服务等)是否有详尽的了解?

您知道每种脚本,资源或CSS的确切影响吗? 他们在页面渲染期间的角色? 所有这些都需要什么才能正常工作? 它到底是做什么的

您是否知道代码的哪些部分由您的前端团队使用和控制,以及哪些部分是所使用的后端技术所固有的,因此很难修改?

请注意, 我不判断你的答案 。 :在某些情况下,我本人会拥有此知识(由专业知识,工具,文档等领导),而在其他情况下,我则根本不具备。

精通这些知识是可取的,但有时很难获得或无法获得。

不同级别的实施

如果您能够对上述所有问题回答是,那么您肯定会知道可以部署哪些指令。 通过仅Content-Security-Policy-Report-Only开始部署,以防止指令不正确地干扰元素加载。 并使用report-uri检索违规。 从逻辑上讲,这应该进行得很好。 最多,您可能需要进行一些简单的调整,然后才能进行部署。 映射前端发生的事情是工作中最困难的部分。

如果您缺乏这些知识,则必须填补这一空白并逐步部署CSP,一次将皮带拉紧一个缺口。

在2017年巴黎网络(由Dareboost赞助)期间,我为一个研讨会提出了动画,提出了一个五步方法来实施CSP。
再一次,这些步骤不应被视为您工作的判断! 在某些情况下,我本人仍处于第一阶段,因为我没有机会继续前进。

而是将其视为您的最佳权重 (较高级别的限制包括先前级别的限制)。 另一个重要的观点是, 如果您可以借用不同级别的元素而不必完全实现它们,请不要犹豫

提醒您:在实施期间,请务必遵守Content-Security-Report-Only规定,除了我将要指示的指令之外,还要指定指令report-uri 。 在可用于CSP的存储库中,我列出了几种针对浏览器检测到的违规行为的检索方法(发送电子邮件,JSON对象,数据库存储等),这些方法将帮助您适应控制策略。

一星实施

 Content-Security-Policy: default-src * data: ; script-src * 'unsafe-inline' 'unsafe-eval' ; style-src * 'unsafe-inline' data: ; frame-ancestors 'none' ; # none or what you authorize 

由于有必要从头开始,因此该第一级允许网站上发生的所有事情(在线脚本/ CSS, eval函数,data-uri,所有来源等)。 此策略仅限制将网站嵌入框架中的可能性。 这等效于X-Frame-Options标头(除此之外,您可以精确定义frame-ancestors的源)。 这应该是您的最低要求

两星级实施

坦率地说:上一级别仅能保护您免受点击劫持攻击的侵害。 现在,我们将为各种元素指定您的授权来源,以便更具限制性。

 Content-Security-Policy: default-src 'self' data: ; script-src 'self' www.foo.com 'unsafe-inline' 'unsafe-eval' ; style-src 'self' www.couaccouac.com 'unsafe-inline' data: ; frame-ancestors 'none' ; base-uri 'none' ; # none or what you authorize 

在这里,您可以指定源(阻止使用通配符“ *”选择器),并设置base-uri (根据base元素的使用,将其设置为none或所需的值: self等)。

三星级实施

先前的级别限制了起源,但是许多东西仍然被授权。 让我们看一下网络字体和CSS。

 Content-Security-Policy: default-src 'self' data: ; script-src 'self' www.foo.com 'unsafe-inline' 'unsafe-eval' ; style-src 'self' www.couacoac.com data: ; font-src 'self' ; frame-ancestors 'none' ; base-uri 'none' ; 

与2星级别相比,区别在于我们决定禁止对样式进行unsafe-inline (因此,不再有不受哈希/ nonce保护的内联样式,并且在HTML元素上也不再具有style属性),并且还消除了危险的可能性JS的data-uri数量(强烈建议不要这样做,因为XSS攻击的强大载体)。

这可能是第一个困难的级别,因为它需要重新考虑页面上某些样式的设置方式。 例如,不幸的是,倾向于设置内联样式的脚本将不得不清除或替换。 虽然这乍看起来似乎是一个限制,但是您的网站也将不再受这些可能令人讨厌的样式的影响而受益。

如果您认为样式只能是无害的,请阅读以下内容:CSS Exfil漏洞。

至于网络字体,请查看如何使用CSS和Webfonts创建键盘记录程序。

四星级实施

掌握CSS已经迈出了第一步,而不是丝毫。 可以想象,但这不是XSS攻击的主要媒介。 现在是时候解决JavaScript权限问题了!

 Content-Security-Policy: default-src 'self' ; script-src 'self' www.foo.com sha256-abcdef ; style-src 'self' www.couacouac.com data: ; font-src 'self' ; frame-ancestors 'none' ; base-uri 'none' ; 

在这里,我们对JavaScript脚本增加了严格的限制:不再有unsafe-inline 。 换句话说,您的内联脚本受哈希/随机数保护,或者存储在由认可来源提供的外部文件中。

并且您能限制这个太危险的eval函数吗? 🙂禁止自己使用unsafe-eval来缩短整个攻击范围。 最好的。

这是第二个重要步骤,可能很难达到。 如果您的后端生成脚本(例如,SharePoint),则您将不得不学习在没有脚本的情况下执行操作,或者确保您的后端还生成无需授权内联脚本即可授权的现时/哈希值。 否则,您还需要“枚举”内联脚本进行授权(通过随机数或哈希值)。

此级别将迫使您的后端团队和前端团队协同工作,以完全控制您的站点。

五星级实施

经过两个严格的级别来确保您掌握了CSS和JS的导入之后,这个“最后一个”级别似乎……很容易达到。 它涉及不隐式授权任何内容。

 Content-Security-Policy: default-src 'none' ; script-src 'self' www.foo.com ; style-src 'self' www.couacouac.com data: ; font-src 'self' ; frame-ancestors 'none' ; base-uri 'none' ; 

您可以进一步详细说明,以完善您的需求,但对于这些指令,将default-srcnone ,则默认情况下将阻止所有内容:

  • 连接源
  • 字体源
  • 帧源
  • img-src
  • 媒体源
  • 对象源
  • 脚本源
  • 样式源
  • worker-src(CSP 3)
  • manifest-src(CSP 3)

逐个指令解锁资源指令将使您对前端发生的事情有清晰的了解,以便您做出反应和适应。

如果不需要插件,请确保将object-src设置为none 。 也不要忘记form-action指令。

超越无限!

不要把最后一步视为绝对成就。 您一定会很高兴到达那里,但是仍然可以对指令进行微调
CSP 2可以通过路径限制来源 (例如,您只能从特定路径(如foo.com/scripts )授权文件)。

如果可以,请优先考虑完整性检查(哈希) 。 他们将保护您免受您自己的团队的无意和不明智的更改。

CSP 3将更加严格:您将只能授权受SubResource Integrity(SRI)保护的脚本和/或样式,也可以通过哈希检查外部文件(目前,仅内联脚本/样式可以受益) ),甚至通过要求脚本受SRI保护并且哈希值属于显式值列表来结合这两种可能性。

换句话说:如果您已经达到这些级别,而这还不够,那么您的问题就不再是CSP…,而是最有可能是安全链的其他部分 。 这甚至可能涉及雇用专业技术人员,他们将致力于管理您对安全性的需求! 🙂

结论

CSP具有此独特功能:它是一种安全技术,涉及后端团队和前端团队(甚至非常强烈地涉及后者)。

始终对CSP 务实 (不仅限于CSP):针对与您的需求和上下文相关的指令 。 如果您有机会提前计划,它总是容易得多。 不要犹豫,参与并解释那些非常关注局限性且并不总是了解所追求目标的营销团队的职能和利益。 重新设计是清理前端代码,强加良好实践和保持清醒的好时机。

另外,请不要犹豫,设置一个能够报告您的CSP所发现违规行为的持续集成。 可以从内部警告系统(可以防止重复违反您的指令)到可以扫描候选站点版本以进行生产并验证没有关键依赖项被阻止的系统,这可能有所不同。

您也可以一个接一个地构建CSP友好组件。 这可能需要很长时间,但值得。

如果您使用Dareboost,您必须已经注意到许多第三方服务并不像您对质量的关注那样。 CSP是挑战它们的另一个原因……或更节俭地使用它们!

我衷心感谢 Boris Schapira Philippe Guilbert 所做的所有微调和重新制定工作。

其他资源

资源附加

  • Mozilla的《 Mozilla天文台》
  • «内容安全策略,您未来的最好朋友»,尼古拉斯·霍夫曼(Smashing Magazine)
  • «内容安全策略»,尼古拉斯·霍夫曼(Openweb,法语)
  • «SubResource Integrity»,尼古拉斯·霍夫曼(Openweb,法语)
  • 尼古拉斯·霍夫曼(Nicolas Hoffmann)的“ HTTPS上的水平浏览和安全性”(Alsacréations,法语)