硬核观察 #1223 Mozilla 认为 “可信类型” 是一项值得信赖的安全功能
1 Mozilla 认为 “可信类型” 是一项值得信赖的安全功能Mozilla 上周改变了其对一项名为 “ 可信类型 Trusted Types ” 的网络安全技术的立场，并决定在其 Firefox 浏览器中实施该技术。这将有助于减少一种长期存在的 XSS 网络攻击。自 2020 年 5 月在 Chrome 83 和 Edge 83 中推出可信类型以来，谷歌网站上的 DOM-XSS 攻击已变得稀少。XSS 攻击在 2017 年的 OWASP 十大 Web 应用程序安全风险注入类别中排名第一，但到 2021 年，它已滑落到最常见漏洞的第三位。（插图：DA/630031a9-b662-40a6-b7f0-98c305d55169）消息来源：The Register老王点评：谷歌可以说是以一己之力干掉了 XSS，但我没想到谷歌做出的重大进步居然需要这么久才得到 Mozilla 的认可。2 Midjourney V6 发布 alpha 版，支持内嵌文字Midjourney 于昨晚发布了该版本。在这些新功能中，包括大幅改进、更逼真、细节更丰富的图像，以及最重要的，让模型在图像中生成可读文本的功能。该功能是 Midjourney 自 2022 年发布以来一直未能实现的功能，而竞争对手 DALL-E 3 已经可以较好的实现该功能。Midjourney 称，V6 实际上是 “在我们的人工智能超级集群上从头开始训练的第三个模型”，花了九个月的时间才开发完成。（插图：DA/76984315-d731-4c84-b681-d68a0329e8d8）消息来源：Venture Beat老王点评：DALL-E 3 太香了，所以我已经有一段时间不使用 Midjourney 了，但是我刚刚用 MJ 和 DA 分别生成“一个人工智能程序在写字板上写到‘我是AI’。”，结果依然令人失望，所以这个插图仍然是 DA 生成的。说来或许是错觉，今天 DA 生成图片中的文字格外精准。3 IT 领域的女性还需要 283 年才能达到男女平等根据英国的一份报告，女性在 IT 领域的人数需要 283 年才能在英国的技术人员队伍中占到与男性同等的比例。根据英国特许信息技术协会（BCS）的调查，女性在 IT 劳动力中的比例目前为 20%，但在 2018 年该比例仅为 16%。还有一个数据值得注意，94% 的女孩和 79% 的男孩在 14 岁时就放弃了计算机。（插图：DA/66ed7991-0810-4e09-8014-a11a7f2ec110）消息来源：The Register老王点评：好吧，我觉得或许不用 283 年，就不存在 IT 领域了。
很久之前，我的个人网站被攻击了。我不知道它是如何发生的，但它确实发生了。幸运的是，攻击带来的破坏是很小的：一小段 JavaScript 被注入到了某些页面的底部。我更新了 FTP 和其它的口令，清理了一些文件，事情就这样结束了。有一点使我很恼火：在当时，还没有一种简便的方案能够使我知道那里有问题，更重要的是能够保护网站的访客不被这段恼人的代码所扰。现在有一种方案出现了，这种技术在上述两方面都十分的成功。它就是 内容安全策略 （ content security policy ） （CSP）。什么是 CSP?其核心思想十分简单：网站通过发送一个 CSP 头部，来告诉浏览器什么是被授权执行的与什么是需要被禁止的。这里有一个 PHP 的例子：<?php header("Content-Security-Policy: <your directives>"); ?> 一些指令你可以定义一些全局规则或者定义一些涉及某一类资源的规则：default-src 'self' ; # self = 同端口，同域名，同协议 => 允许 基础参数是 default-src：如果没有为某一类资源设置指令规则，那么浏览器就会使用这个默认参数值。script-src 'self' www.google-analytics.com ; # 来自这些域名的 JS 文件 => 允许 在这个例子中，我们已经授权了 www.google-analytics.com 这个域名来源的 JavaScript 文件使用到我们的网站上。我们也添加了 'self' 这个关键词；如果我们通过 script-src 来重新设置其它的规则指令，它将会覆盖 default-src 规则。如果没有指明协议（scheme）或端口，它就会强制选择与当前页面相同的协议或端口。这样做防止了混合内容（LCTT 译注：混合内容指 HTTPS 页面中也有非 HTTPS 资源，可参见： https://developer.mozilla.org/zh-CN/docs/Security/MixedContent ）。如果页面是 https://example.com，那么你将无法加载 http://www.google-analytics.com/file.js 因为它已经被禁止了（协议不匹配）。然而，有一个例外就是协议的提升是被允许的。如果 http://example.com 尝试加载 https://www.google-analytics.com/file.js，接着协议或端口允许被更改以便协议的提升。style-src 'self' data: ; # Data-Uri 嵌入 CSS => 允许 在这个例子中，关键词 data: 授权了在 CSS 文件中 data 内嵌内容。在 CSP 1 规范下，你也可以设置如下规则：img-src 有效的图片来源connect-src 应用于 XMLHttpRequest（AJAX），WebSocket 或 EventSourcefont-src 有效的字体来源object-src 有效的插件来源（例如， ， ，<applet>）media-src 有效的 和 来源CSP 2 规范包含了如下规则：child-src 有效的 web workers 和 元素来源，如 和 （这个指令用来替代 CSP 1 中废弃了的 frame-src 指令）form-action 可以作为 HTML 的 action 的有效来源frame-ancestors 使用 ， ， ， 或 <applet> 内嵌资源的有效来源upgrade-insecure-requests 命令用户代理来重写 URL 协议，将 HTTP 改到 HTTPS （为一些需要重写大量陈旧 URL 的网站提供了方便）。为了更好的向后兼容一些废弃的属性，你可以简单的复制当前指令的内容同时为那个废弃的指令创建一个相同的副本。例如，你可以复制 child-src 的内容同时在 frame-src 中添加一份相同的副本。CSP 2 允许你添加路径到白名单中（CSP 1 只允许域名被添加到白名单中）。因此，相较于将整个 www.foo.com 域添加到白名单，你可以通过添加 www.foo.com/some/folder 这样的路径到白名单中来作更多的限制。这个需要浏览器中 CSP 2 的支持，但它很明显更安全。一个例子我为 Web 2015 巴黎大会上我的演讲 “CSP in Action”制作了一个简单的例子。在没有 CSP 的情况下，页面展示如下图所示：不是十分优美。要是我们启用了如下的 CSP 指令又会怎样呢？<?php header("Content-Security-Policy: default-src 'self' ; script-src 'self' www.google-analytics.com stats.g.doubleclick.net ; style-src 'self' data: ; img-src 'self' www.google-analytics.com stats.g.doubleclick.net data: ; frame-src 'self' ;"); ?> 浏览器将会作什么呢？它会（非常严格的）在 CSP 基础规则之下应用这些指令，这意味着任何没有在 CSP 指令中被授权允许的都将会被禁止（“blocked” 指的是不被执行、不被显示并且不被使用在网站中）。在 CSP 的默认设置中，内联脚本和样式是不被授权的，意味着每一个 你应该在 script-src 指令中添加 sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng= 作为有效来源。这个散列值用下面的 PHP 脚本执行获得的结果：<?php echo base64_encode(hash('sha256', "alert('Hello, world.');", true)); ?> 我在前文中说过 CSP 被设计用来降低 XSS 风险，我还得加上“……与降低未经请求内容的风险。”伴随着 CSP 的使用，你必须知道你内容的来源是哪里与它们在你的前端都作了些什么（内联样式，等）。CSP 同时可以帮助你让贡献者、开发人员和其他人员来遵循你内容来源的规则！现在你的问题就只是，“不错，这很好，但是我们如何在生产环境中使用它呢？”如何在现实世界中使用它想要在第一次使用 CSP 之后就失望透顶的方法就是在生产环境中测试。不要想当然的认为，“这会很简单。我的代码是完美并且相当清晰的。”不要这样作。我这样干过。相信我，这相当的蠢。正如我之前说明的，CSP 指令由 CSP 头部来激活，这中间没有过渡阶段。你恰恰就是其中的薄弱环节。你可能会忘记授权某些东西或者遗忘了你网站中的一小段代码。CSP 不会饶恕你的疏忽。然而，CSP 的两个特性将这个问题变得相当的简单。report-uri还记得 CSP 发送到终端中的那些通知么？report-uri 指令可以被用来告诉浏览器发送那些通知到指定的地址。报告以 JSON 格式送出。report-uri /csp-parser.php ; 因此，我们可以在 csp-parser.php 文件中处理有浏览器送出的数据。这里有一个由 PHP 实现的最基础的例子：$data = file_get_contents('php://input'); if ($data = json_decode($data, true)) { $data = json_encode( $data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES ); mail(EMAIL, SUBJECT, $data); } 这个通知将会被转换成为一封邮件。在开发过程中，你可能不会需要比这更复杂的其它东西。对于一个生产环境（或者是一个有较多访问的开发环境），你应该使用一种比邮件更好的收集信息的方式，因为这种方式在节点上没有验证和速率限制，并且 CSP 可能变得乱哄哄的。只需想像一个会产生 100 个 CSP 通知（例如，一个从未授权来源展示图片的脚本）并且每天会被浏览 100 次的页面，那你就会每天收到 10000 个通知啊！例如 report-uri.io 这样的服务可以用来简化你的通知管理。你也可以在 GitHub上看一些另外的使用 report-uri （与数据库搭配，添加一些优化，等）的简单例子。report-only正如我们所见的，最大的问题就是在使用和不使用 CSP 之间没有中间地带。然而，一个名为 report-only 的特性会发送一个稍有不同的头部：<?php header("Content-Security-Policy-Report-Only: <your directives>"); ?> 总的来说，这个头部就是告诉浏览器，“表现得似乎所有的 CSP 指令都被应用了，但是不禁止任何东西。只是发送通知给自己。”这是一种相当棒的测试指令的方式，避免了任何有价值的东西被禁止的风险。在 report-only 和 report-uri 的帮助下你可以毫无风险的测试 CSP 指令，并且可以实时的监控网站上一切与 CSP 相关的内容。这两个特性对部署和维护 CSP 来说真是相当的有用！结论为什么 CSP 很酷CSP 对你的用户来说是尤其重要的：他们在你的网站上不再需要遭受任何的未经请求的脚本，内容或 XSS 的威胁了。对于网站维护者来说 CSP 最重要的优势就是可感知。如果你对图片来源设置了严格的规则，这时一个脚本小子尝试在你的网站上插入一张未授权来源的图片，那么这张图片就会被禁止，并且你会在第一时间收到提醒。开发者也需要确切的知道他们的前端代码都在做些什么，CSP 可以帮助他们掌控一切。会促使他们去重构他们代码中的某些部分（避免内联函数和样式，等）并且促使他们遵循最佳实践。如何让 CSP 变得更酷讽刺的是，CSP 在一些浏览器中过分的高效了，在和书签栏小程序一起使用时会产生一些 bug。因此，不要更新你的 CSP 指令来允许书签栏小程序。我们无法单独的责备任何一个浏览器；它们都有些问题：FirefoxChrome (Blink)WebKit大多数情况下，这些 bug 都是禁止通知中的误报。所有的浏览器提供者都在努力解决这些问题，因此我们可以期待很快就会被解决。无论怎样，这都不会成为你使用 CSP 的绊脚石。via: https://www.smashingmagazine.com/2016/09/content-security-policy-your-future-best-friend/作者：Nicolas Hoffmann 译者：wcnnbdk1 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出