From 23164f48f21b5ed8d43c87bbe167cc99ba296ab0 Mon Sep 17 00:00:00 2001 From: Zhiwei Li <65117011+Levix@users.noreply.github.com> Date: Tue, 29 Nov 2022 20:04:16 +0800 Subject: [PATCH] feat: add security chapter to 2022/zh-CN directory (#3278) * feat: add security chapter to 2022/zh-CN directory * feat: add security chapter to chinese * feat: add security chapter to chinese * Align line numbers * Fix file generation error * Fix linting errors * Add Contributor profile * Remove untranslated file * Add avatar * Remove /en-US/ from MDN links as they redirect * Fix links * Fix links * Fix linting * fix: translate error. Co-authored-by: Barry Pollard --- src/config/2022.json | 8 + src/content/en/2022/security.md | 2 - src/content/zh-CN/2022/security.md | 1280 ++++++++++++++++++++++++++++ 3 files changed, 1288 insertions(+), 2 deletions(-) create mode 100644 src/content/zh-CN/2022/security.md diff --git a/src/config/2022.json b/src/config/2022.json index e720d4db187..5b5e46cdb94 100644 --- a/src/config/2022.json +++ b/src/config/2022.json @@ -1281,6 +1281,14 @@ ], "github":"yokoka" }, + "Levix":{ + "name": "Zhiwei Li", + "teams":[ + "translators" + ], + "avatar_url": "65117011", + "github":"Levix" + }, "luckybai": { "name": "Zongchao Bai", "teams": [ diff --git a/src/content/en/2022/security.md b/src/content/en/2022/security.md index ada9c616a81..7a062874e01 100644 --- a/src/content/en/2022/security.md +++ b/src/content/en/2022/security.md @@ -256,7 +256,6 @@ There are two different ways to set the time when a cookie is deleted: `Max-Age` Unlike last year, where we saw that the median for `Max-Age` was 365 days but the median for `Expires` was 180 days, this year it's around 365 days for both. Hence the median for real maximum age has gone up from 180 days to 365 days this year. Even though the `Max-Age` is 729 days and `Expires` is 730 days in the 90th percentile, Chrome has been planning to put a cap of 400 days for both `Max-Age` and `Expires`. -
@@ -543,7 +542,6 @@ Subresource integrity is specified as a base64 string of a computed hash of one Consistent with last year's report, SHA384 continues to demonstrate the majority of SRI hash types observed between all available hash functions. - CDNs are no strangers to Subresource Integrity and provide secure defaults to their consumers by including a Subresource Integrity value as part of their URL references for content to be served on the page.
diff --git a/src/content/zh-CN/2022/security.md b/src/content/zh-CN/2022/security.md new file mode 100644 index 00000000000..60486b0816c --- /dev/null +++ b/src/content/zh-CN/2022/security.md @@ -0,0 +1,1280 @@ +--- +#See https://github.com/HTTPArchive/almanac.httparchive.org/wiki/Authors'-Guide#metadata-to-add-at-the-top-of-your-chapters +title: 安全 +description: 2022年 Web 年鉴的安全章节，涵盖了传输层安全、内容包含（CSP、Feature Policy、SRI）、Web 防御机制（解决 XSS、XS-Leaks）以及安全机制采用的驱动因素。 +authors: [SaptakS, lirantal, clarkio] +reviewers: [kushaldas, tunetheweb] +analysts: [VictorLeP, vikvanderlinden, GJFR] +editors: [tunetheweb] +translators: [Levix] +SaptakS_bio: Saptak S 是一名以人权为中心的 Web 开发者，专注于 Web 开发中的可用性、安全性、隐私和无障碍性主题。他是各种不同开源项目的贡献者和维护者，如 A11Y 项目, OnionShare 和 Wagtail。你可以在 saptaks.blog 找到他的博客。 +lirantal_bio: Liran Tal 因其开源和 JavaScript 安全倡议而闻名，并在 Node.js 安全方面的工作获得了OpenJS 基金会的安全探路者奖项，是国际公认的 GitHub Star，他是 JavaScript 社区获奖的软件开发人员、安全研究员和开源倡导者。他对开发者安全教育的贡献包括领导 OWASP 项目，建立供应链安全工具，参与 CNCF 和 OpenSSF 计划，并撰写了 O'Reilly 的 《Serverless Security》 等书籍，他领导着 Snyk.io 开发者宣传团队，并以赋予开发者更好的应用安全技能为使命。 +clarkio_bio: Brian 是一位在应用安全方面有深入经验的 Web 开发者，通过在 Snyk.io 担任开发者大使的工作，帮助开发者构建安全的 Web 应用。虽然他有全栈项目的工作经验，但他的重点是后端服务、API 和开发者工具。Brian 喜欢向开发人员传授他从整个职业生涯的成功和失败中学到的东西。你可以在他每周的直播中或在他的 Pluralsight 课程中找到他正在做的事情。 +results: https://docs.google.com/spreadsheets/d/1cwJ43NL2IN2PxJa5oiOoJCRkSh566XE_k9uHnGJdWeg/ +featured_quote: 人们的个人信息以及生活的各个方面每天都在变得越来越数字化，这使得安全和隐私变得极为重要，网站有责任采用最佳的安全实践来确保其用户隐私受到保护。 +featured_stat_1: +14% +featured_stat_label_1: 内容安全策略（CSP）的采用率增加 +featured_stat_2: 428 +featured_stat_label_2: 使用 `Clear-Site-Data` 标头的网站 +featured_stat_3: +85% +featured_stat_label_3: 权限策略（Permissions Policy）的采用率增加 +--- + +## 介绍 + +随着人们的个人信息越来越数字化，安全和隐私在互联网上变得极其重要，网站所有者有责任确保他们从用户那里获取数据的安全性。因此，必须采用所有的安全最佳实践，以确保用户免受恶意软件利用漏洞获取敏感信息的影响。 + +与[往年](../2021/security)一样，我们分析了 Web 社区对安全方法和最佳实践的采用和使用情况。我们分析了与每个网站应该采取的最基本安全措施有关的指标，如[传输安全](#传输安全（transport-security）)和[适当的 cookie 管理](#cookies)。我们还讨论了与采用不同安全头（security headers）有关的数据，以及它们如何帮助 [content inclusion](#内容包含（content-inclusion）) 和[防止各种恶意攻击](#预防攻击)。 + +我们研究了[安全措施的采用](#采用安全机制的驱动因素)与地点、技术栈和网站受欢迎程度的相关性，我们希望通过这种相关性鼓励所有的技术栈在默认情况下采取更好的安全措施。我们还讨论了一些 [well-known URIs](#well-known-uris)，它们有助于基于 Web 应用程序安全工作组的标准和草案进行漏洞披露和其他与安全相关的设置。 + +## 传输安全（Transport security） + +传输层安全保证用户与网站之间的数据和资源的安全通信，[HTTPS](https://developer.mozilla.org//docs/Glossary/https) 使用 TLS 来加密客户端和服务器之间的所有通信。 + +{{ figure_markup( + content="94%", + caption="桌面端使用 HTTPS 的请求占比", + classes="big-number", + sheets_gid="1093490384", + sql_file="https_request_over_time.sql", +) }} + +桌面端 94% 的请求和移动端 93% 的请求都是通过 HTTPS 发送的，所有主流浏览器现在都有一个 HTTPS-only 模式，如果一个网站使用 HTTP 而非 HTTPS，则会显示警告。 + +{{ figure_markup( + image="https-usage-by-site.png", + caption="网站的 HTTPS 使用率", + description="条形图显示 89% 的桌面端站点使用 HTTPS，剩下的 11% 使用 HTTP，而 85% 的移动端站点使用 HTTPS，剩下的 15% 使用 HTTP。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1343950152&format=interactive", + sheets_gid="1806760937", + sql_file="home_page_https_usage.sql" + ) +}} + +与总请求（接口）相比，通过 HTTPS 提供服务的主页比例仍然较低，因为很多对网站的请求都是由[第三方](./third-parties)服务主导的，如字体、CDN 等，这些服务 的 HTTPS 采用率较高。我们看到这个百分比确实比去年略有上升，现在 89.3% 的主页面在桌面端通过 HTTPS 提供服务，而去年这一比例为 84.3%。同样在我们的移动数据统计中 85.5% 的主页面通过 HTTPS 提供服务，而去年为81.2%。 + +### 协议版本 + +重要的是，不仅要使用 HTTPS，而且要使用最新的 TLS 版本，TLS 工作组已经废弃了 TLS v1.0 和 v1.1，因为它们存在多个缺陷。自从去年的章节以来，Firefox 现在已经更新了它的用户界面，在 Firefox 97 版的错误页面中，启用 TLS 1.0 和 1.1 的选项已经被删除。Chrome 也从 98 版本开始不再允许绕过 TLS 1.0 和 1.1 所显示的错误页面。 + +IETF 于 2018 年 8 月发布的 TLS v1.3 是最新版本，相较于 TLS v1.2 版本它更快而且更安全，TLS v1.2 中的许多主要漏洞都与旧加密算法有关，而 TLS v1.3 删除了这些算法。 + +{{ figure_markup( + image="tls-version-by-site.png", + caption="网站的 TLS 版本使用分布", + description="条形图显示桌面端 67% 的站点采用 TLSv1.3, 33% 的站点采用 TLSv1.2 版本。在移动端上，这一数字分别为 70% 和 30%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1390978067&format=interactive", + sheets_gid="1385583211", + sql_file="tls_versions_pages.sql" + ) +}} + +在上图中，我们看到 70% 的移动网页和 67% 的桌面网页是通过 TLSv1.3 提供的，这比去年增加了约 7%。因此，我们看到一些从使用 TLS v1.2 到 TLS v1.3 的持续转变。 + +### 密码套件（Cipher suites） + +密码套件是一组加密算法，客户和服务器在开始使用 TLS 进行安全通信之前必须达成一致。 + +{{ figure_markup( + image="distribution-of-cipher-suites.png", + caption="密码套件的分布", + description="条形图显示了各设备使用的密码套件，`AES_128_GCM` 是最常见的，被 79% 的桌面端网站和 79% 的移动端网站使用，`AES_256_GCM` 被 19% 的桌面端网站和 18% 的移动端网站使用，`AES_256_CBC` 被 2% 的桌面端网站和 1% 的移动端网站使用，`CHACHA20_POLY1305` 分别被 1% 和 1% 的网站使用，`AES_128_CBC` 分别被 0% 和 0% 使用。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1789949340&format=interactive", + sheets_gid="711514835", + sql_file="tls_cipher_suite.sql" + ) +}} + +现代 [Galois/Counter Mode (GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) 密码模式被认为是更安全的，因为它们不容易受到填充攻击（padding attacks）。TLS v1.3 只支持 GCM 和其他现代分组密码模式，使其更加安全，它还消除了密码套件排序的麻烦。决定密码套件使用情况的另一个因素是用于加密和解密的密钥大小，我们看到 128 位的密钥仍然被广泛使用，因此，我们看到与去年的图表对比没有什么不同，`AES_128_GCM` 仍然是使用最多的密码套件，使用率为 79%。 + +{{ figure_markup( + image="forward-secrecy-support.png", + caption="前向保密（Forward secrecy）的使用情况", + description="条形图显示，97% 的移动端和桌面端请求都使用了前向保密。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=298331860&format=interactive", + sheets_gid="1454804483", + sql_file="tls_forward_secrecy.sql" + ) +}} + +TLS v1.3还强制要求[前向保密](https://en.wikipedia.org/wiki/Forward_secrecy)，我们看到 97% 的移动和桌面端请求都使用了它。 + +### 证书颁发机构（CA 认证） + +认证机构或 CA 是一个公司或组织，它向网站颁发可被浏览器识别的 TLS 证书，然后与网站建立一个安全的通信通道。 + +
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
发行机构桌面端移动端
R348%52%
Cloudflare Inc ECC CA-313%12%
Sectigo RSA Domain Validation Secure Server CA7%8%
cPanel, Inc. Certification Authority5%5%
Amazon3%3%
Go Daddy Secure Certificate Authority - G23%2%
DigiCert SHA2 Secure Server CA2%1%
RapidSSL TLS DV RSA Mixed SHA256 2020 CA-11%1%
E11%1%
+
{{ figure_link(caption="十大证书颁发机构", sheets_gid="1306037372", sql_file="tls_ca_issuers_pages.sql") }}
+
+ +Let's Encrypt（或 R3）继续领先，48% 的桌面端网站和 52% 的移动端网站使用他们颁发的证书，Let's Encrypt 作为一个非营利性组织在采用HTTPS 方面发挥了重要作用，他们继续发放越来越多的证书。我们还想花一点时间来纪念它的创始人之一 —— Peter Eckersly，他最近不幸去世了。 + +Cloudflare 以其为客户提供类似的免费证书而继续处于第二位，Cloudflare CDNs 增加了椭圆曲线加密法（ECC）证书的使用，该证书比 RSA 证书更小、更有效，但由于需要继续向老客户端提供非 ECC 证书，因此比较难部署。我们看到，随着 Let's Encrypt 和 Cloudflare 的比例不断增加，其他 CA 的使用比例正在一点点减少。 + +### HTTP 严格传输安全（HSTS） + +[HTTP 严格传输安全（HSTS）](https://developer.mozilla.org//docs/Web/HTTP/Headers/Strict-Transport-Security)是一个标头，它通知浏览器自动将所有使用 HTTP 访问网站的尝试转换为 HTTPS 请求。 + +{{ figure_markup( + content="25%", + caption="具有 HSTS 头的移动端请求", + classes="big-number", + sheets_gid="822440544", + sql_file="hsts_attributes.sql", +) }} + +25% 的移动端响应和 28% 的桌面响应携带 HSTS 头。 + +HSTS 是使用 `Strict-Transport-Security` 请求头来设置的，它可以有三种不同的指令：`max-age`、`includeSubDomains` 和 `preload`。 `max-age` 表示浏览器应该记住只使用 HTTPS 访问网站的时间，以秒为单位，是该请求头的一个强制性指令。 + +{{ figure_markup( + image="hsts-directives-usage.png", + caption="不同 HSTS 指令的使用情况", + description="不同 HSTS 指令使用情况百分比柱状图。19% 的网站在移动和桌面端都使用了 `preload`，`includeSubdomain` 在 37% 的桌面网站和 34% 的移动网站中被使用，6% 的桌面端网站和 5% 的移动端网站使用了 max-age 为 0，94% 的桌面网站和 95% 的移动网站设置了有效的 `max-age`。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=683864207&format=interactive", + sheets_gid="822440544", + sql_file="hsts_attributes.sql" +) }} + +我们看到 94% 的桌面端站点和 95% 的移动端站点都设置了一个非零、非空的 `max-age`。 + +34% 的移动端请求响应，37%的桌面端请求响应在 HSTS 设置中包含了 `includeSubdomain`，而带有 `preload` 指令的响应数量较少，该指令[不属于 HSTS 标准中的一部分](https://developer.mozilla.org//docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security)，它需要设置最小的 `max-age` 为 31,536,000 秒（或1年），且 `includeSubdomain` 指令也要同时存在。 + +{{ figure_markup( + image="hsts-max-age-values-in-days.png", + caption="所有请求的 HSTS `max-age` 值（以天为单位）", + description="`max-age` 属性中数值的百分比柱状图，转换为天数。在第 10 个百分点中，桌面端是 30 天，移动端是 73 天；在第 25 个百分点中，两者都是 180 天；在第 50 个百分点中，两者都是 365 天；第 75 个百分点中，两者都是 365 天；第 90 个百分点中，两者都是 730 天。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=154290094&format=interactive", + sheets_gid="1179482269", + sql_file="hsts_max_age_percentiles.sql" +) }} + +在所有请求中，HSTS 请求头中 `max-age` 属性的中间值是 365 天，在移动和桌面端上都是如此。https://hstspreload.org/ 认为一旦 HSTS 头被正确设置并被验证不会引起任何问题，建议设置 `max-age` 为 2 年。 + +## Cookies + +[HTTP cookie](https://developer.mozilla.org//docs/Web/HTTP/Cookies) 是服务器发送给浏览器关于用户的一组数据，cookie 可用于会话管理、个性化、跟踪和其他与用户在不同请求中的状态信息。 + +如果 cookie 设置不当，可能容易遭受许多不同形式的攻击，例如会话劫持、跨站请求伪造（CSRF）、跨站脚本包含（XSSI）和其他各种跨站泄漏漏洞。 + +### Cookie 属性 + +为了防御上述威胁，开发人员可以在 cookie 中使用 3 个不同的属性：`HttpOnly`、`Secure` 和 `SameSite`。`Secure` 属性类似于 `HSTS` 标头，因为它也确保 cookie 必须通过 HTTPS 发送，防止中间人攻击。`HttpOnly` 确保 cookie 不能被任何 JavaScript 代码访问，防止跨站脚本攻击。 + +{{ figure_markup( + image="httponly-secure-samesite-cookie-usage.png", + caption="Cookie 属性 (桌面端)", + description="桌面端网站上使用 cookie 属性柱状图，按第一方和第三方 cookie 划分。第一方 cookie 使用 `HttpOnly` 的比例为 36%，`Secure` 的比例为 37%，`SameSite` 的比例为 45%，而第三方 cookie 使用`HttpOnly` 的比例为 21%，`Secure` 的比例为 90%，`SameSite` 的比例为 88%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=528777115&format=interactive", + sheets_gid="168091712", + sql_file="cookie_attributes.sql" +) }} + +存在 2 种不同的 cookies：第一方（first-party）和第三方（third-party）。第一方 cookie 通常由你正在访问的直接服务器设置，而第三方 cookie 是由第三方服务创建的，通常用于跟踪和广告服务。桌面端 37% 的第一方 cookie 设置了 `Secure` 字段，36% 设置了 `HttpOnly` 字段，然而，在第三方 cookie 中，我们看到 90% 的 cookie 设置了 `Secure`，21% 设置了 `HttpOnly`。在第三方 cookie 中，`HttpOnly` 的比例较小，因为他们大多数希望允许通过 JavaScript 代码访问它们（跟踪和广告服务）。 + +{{ figure_markup( + image="samesite-cookie-attributes.png", + caption="同站（Same site） cookie 属性", + description="按第一方和第三方划分的 SameSite cookie 属性条形图。对于第一方来说，61% 的用户使用 `SameSite=lax`，2% 的用户使用 `SameSite=strict`，37% 的用户使用 `SameSite=none`，而对于第三方来说，1% 的用户使用 `SameSite=lax`，1% 的用户使用 `SameSite=strict`，98% 的用户使用 `SameSite=none`。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=1714102327&format=interactive", + sheets_gid="168091712", + sql_file="cookie_attributes.sql" +) }} + +`SameSite` 属性可用于防止 CSRF 攻击，它告诉浏览器是否向跨站点请求发送 cookie。`Strict` 属性值只允许将 cookie 发送到它的来源网站，而 `Lax` 值只允许在用户通过链接导航到来源网站时将 cookie 发送到跨网站请求。对于 `None` 值，cookie 将被发送到源站点和跨站点的请求。如果 `SameSite=None` 被设置，cookie 的 `Secure` 属性也必须被设置（否则 cookie 将被阻止）。我们看到 61% 的第一方 cookie 的 `SameSite` 属性值设置为 `Lax`。如果 cookie 没有设置 `SameSite` 属性，大多数浏览器默认设置为 `SameSite=Lax`，因此我们看到它继续在图表中占主导地位。在第三方cookie中，`SameSite=None` 仍然是超高的，在桌面端上有 98% 的 cookie 设置了它，因为第三方 cookie 确实想在跨站请求中发送。 + +### Cookie age + +有两种不同的方式来设置 cookie 的过期时间：`Max-Age` 和 `Expires`。`Expires` 使用一个特定的日期（相对于客户端而言）来决定何时删除 cookie，而 `Max-Age` 使用一个以秒为单位的持续时间。 + +{{ figure_markup( + image="cookie-age-usage-by-site-in-desktop-in-days.png", + caption="Cookie age 的使用，以天为单位（桌面端）", + description="柱状图显示了在不同百分位数上使用 cookie age 的情况。在第 10 个百分位数，`Max-Age` 为 1，`Expires` 为10，实际最大 age 为 7。在第 25 百分位，`Max-Age` 和`Expires` 的值分别为 90 天和 60 天，实际的 age 值是 60 天。在第 50 百分位，`Max-Age`、`Expires` 和真实 age 值为 365 天。在第 75 百分位，`Max-Age`、`Expires` 和真实 age 值为 365 天。在第 90 个百分位数中，`Max-Age`、`Expires` 和实际 age 值为 730 天。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=2015811517&format=interactive", + sheets_gid="1811539513", + sql_file="cookie_age_percentiles.sql" + ) +}} + +与去年不同的是，去年 `Max-Age` 的中位数是 365 天，而 `Expires` 的中位数是 180 天，今年两者都设置在 365 天左右。因此，今年实际 `Max-Age` 的中位数已经从 180 天上升到 365 天，即使 90% 设置了 `Max-Age` 为 729 天，`Expires` 为 730 天。Chrome 浏览器一直计划将 `Max-Age` 和 `Expires` 的上限设定为 400 天。 + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%Expires
1.8%"Thu, 01-Jan-1970 00:00:00 GMT"
1.2%"Fri, 01-Aug-2008 22:45:55 GMT"
0.7%"Mon, 01-Mar-2004 00:00:00 GMT"
0.7%"Thu, 01-Jan-1970 00:00:01 GMT"
0.3%"Thu, 01 Jan 1970 00:00:00 GMT"
+
+ {{ figure_link( + caption="桌面端最常见的 cookie 过期值", + sheets_gid="707972861", + sql_file="cookie_max_age_expires_top_values.sql", + ) }} +
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%Expires
1.2%"Fri, 01-Aug-2008 22:45:55 GMT"
0.9%"Thu, 01-Jan-1970 00:00:00 GMT"
0.7%"Mon, 01-Mar-2004 00:00:00 GMT"
0.6%"Thu, 01-Jan-1970 00:00:01 GMT"
0.2%"Thu, 31-Dec-37 23:55:55 GMT"
+
+ {{ figure_link( + caption="移动端最常见的 cookie 过期值", + sheets_gid="707972861", + sql_file="cookie_max_age_expires_top_values.sql", + ) }} +
+
+ +最普遍的 `Expires` 有一些有趣的值。我们看到，在桌面端使用最多的 `Expires` 值是 `January 1, 1970 00:00:00 GMT`，当 cookies 的 `Expires` 值被设置为过去的日期时，它们会被从浏览器中删除。1970 年 1 月 1 日 00:00:00 GMT 是 Unix 纪元时间，因此它经常被用于设置过期时间或删除一个 cookie。 + +## 内容包含（Content inclusion） + +一个网站内容通常有很多形式，需要 CSS、JavaScript 或其他媒体资源（如字体和图片）等资源，这些资源经常从外部服务提供商那里加载，如云原生基础设施的远程存储服务，或从内容交付网络（CDNs）加载，目的是为了减少全球范围内的网络往返延迟，以提供内容。 + +然而，确保我们在网站上的内容没有被篡改是非常关键的，其影响可能是毁灭性的，随着人们对供应链安全意识的提高，Content inclusion 变得更加重要，Magecart 攻击的事件越来越多，针对网站内容系统，该攻击针对网站内容系统，通过跨站脚本（XSS）漏洞和其它手段注入持久性恶意软件。 + +### 内容安全策略（Content Security Policy，简称 CSP） + +你可以部署一套有效措施来降低围绕内容包含（Content inclusion）的安全风险，即采用内容安全策略（CSP），它是一种安全标准，添加了一个深度防御层，以减轻通过跨站脚本编写代码注入或点击劫持等攻击。 + +它的工作原理是确保预先定义的受信任内容规则集得到维护，并拒绝任何绕过或包括受限制内容的尝试。例如，内容安全策略允许 JavaScript 代码仅在其提供的同源站点和 Google Analytics 的浏览器中运行，该策略将被定义为 `script-src 'self' www.google-analytics.com;`。任何跨站脚本注入的尝试，如 ``，都会被执行设定策略（CSP）的浏览器拒绝。 + +{{ figure_markup( + caption="相比于 2021 年，内容安全策略标头的采用率相对增加", + content="+14%", + classes="big-number", + sheets_gid="1799124531", + sql_file="security_headers_prevalence.sql" +) +}} + +我们看到，从 2021 年 12.8% 的数据到 2022 年 14.6% 的数据，这表明在开发人员和 web 安全社区中采用 `Content-Security-Policy` 标头的趋势在不断增长，这是积极的，尽管使用这种更高级功能的网站仍然是少数。 + +当 CSP 被用于 HTML 响应本身时，它是最有用的。在这里，我们看到使用 CSP 标头的移动端请求使用率持续增长，两年前为 7.2%，去年为 9.3%，今年为 11.2%。 + +{{ figure_markup( + image="csp-directives-usage.png", + caption="CSP中最常用的指令", + description="条形图显示了最常见的 CSP 指令使用情况。`upgrade-insecure-requests` 是最常见的，在桌面端占 54%，在移动端占 56%；其次是 `frame-ancestors`，在桌面端占54%，在移动端占 53%；`block-all-mixed-content` 在桌面端占 26%，在移动端占 38%；`default-src` 在桌面端占 19%，在移动端占 16%；`script-src` 在桌面端占 17%，在移动端占 15%；`style-src` 在桌面端占 14%，在移动端占 12%；`img-src` 在桌面端占 13%，在移动端占 11%；`font-src` 在桌面端占 11%，在移动端占 9%，`connect-src` 在桌面端占 10%，在移动端占 8%，`frame-src` 在桌面端占 10%，在移动端占 7%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=417279434&format=interactive", + sheets_gid="1303493233", + sql_file="csp_directives_usage.sql" + ) +}} + +我们看到，在桌面端和移动端的 HTTP 请求中，排在前三位的 CSP 指令是 `upgrade-insecure-requests`（占 54%）、`frame-ancestors`（占 54%）、`block-all-mixed-content`（占 27%）策略，排名靠后的策略有 `default-src`、`script-src`、`style-src` 和 `img-src` 等等。 + +`upgrade-insecure-requests` 策略的高采用率也许归功于 TLS 请求作为业界标准（de-facto standard）的高采用率。然而，尽管 `block-all-mixed-content` 被认为已经过时，但它的采用率依旧很高，这也许说明了 CSP 规范的发展速度之快，用户很难跟上时代的步伐。 + +在减少跨站脚本攻击方面，谷歌针对[Trusted Types](https://developer.mozilla.org//docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types)的安全倡议做得更多，它需要本地浏览器 API 支持，以帮助防止 DOM 注入类漏洞，它是由谷歌工程师积极倡导的，但仍处于 W3C 的建议草案阶段，尽管如此，我们将其 CSP 相关的安全头 `require-trusted-types-for` 和 `trusted-types` 记录在 0.1% 的请求中，这并不多，但也许说明采用这种方法的趋势正在增长。 + +为了评估是否发生了违反预先定义规则集的 CSP 行为，网站可以设置 `report-uri` 指令，让浏览器将 JSON 格式数据作为 HTTP POST 请求发送。尽管 `report-uri` 请求占所有带有 CSP 标头桌面流量的 4.3%，但到目前为止，它已被废弃，被 `report-to` 取代，它占桌面请求的 1.8%。 + +实施严格的内容安全策略的最大挑战之一是内联 JavaScript 代码的存在，这些代码通常被设置为事件处理程序或在 DOM 的其他部分。为了允许团队逐步采用 CSP 安全标准，策略可以将 `unsafe-inline` 或 `unsafe-eval` 作为其 `script-src` 指令的关键值，这样做，不能防止一些跨站脚本攻击载体，并且对策略的预防措施产生反作用。 + +团队可以通过使用 nonce 或 SHA256 哈希对内联 JavaScript 代码进行签名，从而使其更安全。看起来就像这样： + +``` +Content-Security-Policy: script-src 'nonce-4891cc7b20c' +``` + +然后在HTML中引用它： + +```html + +``` + +{{ figure_markup( + image="csp-script-src-attribute-usage.png", + caption="CSP `script-src` 属性的使用情况", + description="柱状图显示了在 CSP `script-src` 指令中 nonce、`unsafe-inline` 和 `unsafe-eval` 的使用情况。`nonce-` 被用于 12% 带有 CSP 标头的移动网站和 14% 的桌面网站；`unsafe-inline` 在移动端有 94% 的网站使用，在桌面端有 95%；`unsafe-eval` 在这类网站中的使用，移动端占 80%，桌面端占 78%。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=310998764&format=interactive", + sheets_gid="323360740", + sql_file="csp_script_source_list_keywords.sql" + ) +}} + +对所有桌面端 HTTP 请求进行的统计显示，94% 的（页面）设置了 `unsafe-inline`，80% 的（页面） `script-src` 值设置为 `unsafe-eval`，这表明在锁定网站的应用代码以避免内联 JavaScript 代码方面存在真正的挑战。此外，只有 14% 的上述请求采用了 `nonce-` 指令，这有助于确保不安全的内联 JavaScript 代码的使用。 + +我们观察到 CSP 标头长度的统计数据也许说明了定义内容安全策略的高度复杂性。 + +{{ figure_markup( + image="csp-header-length.png", + caption="CSP 标头长度", + description="柱状图显示了以字节为单位的 CSP 标头长度百分比数据。在第 10 个百分点，桌面端和移动端都是 22 个字节，在第 25 个百分点，都是 25 个字节，在第 50 个百分点，桌面端是 64 个字节，移动端是 70 个字节，在第 75 个百分点都是 75 个字节，在第 90 个百分点，桌面端是 494 个字节，移动端是 334 个字节。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=311379301&format=interactive", + sheets_gid="54898794", + sql_file="csp_number_of_allowed_hosts.sql" +) }} + +在中位数的排名中，50% 的桌面端请求中大小只达到 70 个字节，这比去年的数据略有下降，去年的报告显示桌面端和移动端请求的大小都是 75 个字节。90% 以上的请求从去年的 389 个字节增长到了今年的 494 个字节，这表明朝着更加复杂和完整的安全策略方向取得了微小的进展。 + +观察内容安全策略的完整定义，我们可以看到单个指令仍然占所有请求的很大比例。19% 的桌面端请求被设置为 `upgrade-insecure-requests`，8% 的桌面端请求被设置为 `frame-ancestors 'self'`，23% 的桌面端请求被设置为 `block-all-mixed-content; frame-ancestors 'none'; upgrade-insecure-requests;`，它混合了最常见的 3 个 CSP 指令。 + +内容安全策略通常必须允许来自其他源的内容，而不是自己的内容，以支持加载媒体，如字体、广告相关脚本和一般内容交付网络的使用，因此，整个请求的前 10 个来源如下： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Origin桌面端移动端
https://www.google-analytics.com0.39%0.26%
https://www.googletagmanager.com0.37%0.25%
https://fonts.gstatic.com0.27%0.19%
https://fonts.googleapis.com0.27%0.18%
https://www.google.com0.24%0.17%
https://www.youtube.com0.21%0.15%
https://stats.g.doubleclick.net0.19%0.13%
https://connect.facebook.net0.18%0.13%
https://www.gstatic.com0.17%0.12%
https://cdnjs.cloudflare.com0.16%0.11%
+
+ {{ figure_link( + caption="CSP 策略中最常被允许的提供商", + sheets_gid="106248959", + sql_file="csp_allowed_host_frequency.sql" + ) }} +
+
+ +上述提供商的排名与去年报告的大致相同，但使用量略有上升。 + +CSP 安全标准得到了 Web 浏览器以及内容传输网络和内容管理系统的广泛支持，是网站和 web 应用防御 web 安全漏洞的一个强烈推荐工具。 + +### 子资源完整性（Subresource Integrity，简称 SRI） + +另一个深度防御工具是子资源完整性，它提供了一个 Web 安全防御层，防止内容被篡改，内容安全策略定义了允许的内容类型和来源，而子资源完整性机制确保上述内容没有被恶意修改。 + +使用子资源完整性的一个参考用例是当从第三方包管理器加载 JavaScript 内容时，第三方包管理器也充当 CDN，例如 unpkg.com 或 cdnjs.com，它们都为 JavaScript 库的内容资源提供服务。 + +如果第三方库可能因为 CDN 提供商的托管问题，或项目贡献者或维护者的问题而被破坏，那么你实际上是在把别人的代码加载到你的网站上。 + +与 CSP 使用 `nonce-` 类似，子资源完整性（也称为 SRI）允许浏览器验证所提供的内容是否与加密签名的哈希值相符，并防止内容被篡改，无论是通过网络还是在其源头。 + +{{ figure_markup( + content="20%", + caption="使用 SRI 的桌面站点", + classes="big-number", + sheets_gid="953586778", + sql_file="sri_usage.sql", +) }} + +大约每 5 个网站中就有一个（20%）在桌面端网页元素中设置了子资源完整性，其中，83% 专门用于桌面端的 ` +``` + +{{ figure_markup( + image="sri-hash-function-usage.png", + caption="SRI 哈希函数", + description="条形图显示使用各种哈希函数的 SRI 元素百分比。桌面端网站中 58.4% 的 SRI 元素和移动端网站中 60.7% 的 SRI 元素使用了 SHA-384；桌面端网站中 32.4% 的 SRI 元素和移动端网站中 30.8% 的 SRI 元素使用了 SHA-256；桌面端网站中 10.9% 的 SRI 元素和移动端网站中 9.9% 的 SRI 元素使用了 SHA-512。", + chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vSPHK3G2Ir-ys_oTrrhugqxV0aOSj3y5d1lANQ54GdaQtIHrzXIjQQGEpIdT_mQvxTrMtpd0Hn30zhF/pubchart?oid=699960446&format=interactive", + sheets_gid="1419400151", + sql_file="sri_hash_functions.sql" +) }} + +与去年的报告一致，SHA384 继续展示了在所有可用的哈希函数中被使用最多的 SRI 哈希类型。 + +CDNs 对子资源完整性并不陌生，通过在页面内容的 URL 引用中包含子资源完整性值，向其调用者提供安全的默认值。 + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Host桌面端移动端
www.gstatic.com39%40%
cdn.shopify.com22%23%
cdnjs.cloudflare.com8%7%
code.jquery.com7%7%
static.cloudflareinsights.com5%4%
cdn.jsdelivr.net3%3%
t1.daumcdn.net3%1%
stackpath.bootstrapcdn.com2.7%2.7%
maxcdn.bootstrapcdn.com2.2%2.3%
+
{{ figure_link(caption="包括 SRI 保护脚本的大多数常见提供商", sheets_gid="998292064", sql_file="sri_popular_hosts.sql") }}
+
+ +上述列表显示了已观察到子资源完整性值的前 10 个最常见的提供商，与去年相比，值得注意的变化是 Cloudflare 提供商从第 4 位跃升至第 3 位，jsDelivr 的排名从第 7 位跳到第 6 位，超过了 Bootstrap 提供商排名。 + +### 权限策略（Permissions Policy） + +随着时间的推移，浏览器变得越来越强大，添加了更多的原生 API 来访问和控制不同种类的硬件和网站提供的功能集。通过滥用上述功能，也会给用户带来潜在的安全风险，例如恶意脚本打开麦克风并收集数据，或通过指纹识别设备的地理位置来收集位置信息。 + +以前被称为 `Feature-Policy`，现在被命名为 `Permissions-Policy`，这是一个实验性的浏览器 API，能够控制浏览器访问一系列功能的白名单列表和黑名单列表。 + +我们注意到 `Permissions-Policy` 的使用与启用 HTTPS 连接（97%）、`X-Content-Type-Options`（82%）以及 `X-Frame-Options`（78%）高度相关，所有的相关性都是跨桌面端请求。另一个高相关性是在特定的技术交叉点，观察到的是 Google My Business 移动端页面（99%），其次是 Acquia 的云平台（67%）。所有的相关性都是跨移动端请求。 + +{{ figure_markup( + caption="从2021年开始， `Permissions-Policy` 的采用率相对增加", + content="+85%", + classes="big-number", + sheets_gid="1799124531", + sql_file="security_headers_prevalence.sql" +) +}} + +我们看到，从 2021 年的数据（1.3%）到 2022 年的数据（2.4%），移动端请求对 `Permissions-Policy` 的采用率相对增加了 85%，桌面端请求也有类似的趋势。被废弃的 `Feature-Policy` 在去年和今年的数据之间出现了 1% 的微弱增长，这表明用户正在跟上 Web 浏览器规范的变化。 + +除了作为 HTTP 标头之外，该特性还可以在 ` +``` + +在移动端的 1150 万个框架中，有 18.9% 包含 `allow` 属性，以启用权限或特性策略。 + +以下是在框架中检测到的前 10 条 `allow` 指令列表： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
指令桌面端移动端
`encrypted-media`75%75%
`autoplay`48%49%
`picture-in-picture`31%31%
`accelerometer`26%27%
`gyroscope`26%27%
`clipboard-write`21%21%
`microphone`9%9%
`fullscreen`8%7%
`camera`6%7%
`geolocation`5%6%
+
+ {{ figure_link( + caption="iframes 上 `allow` 指令的普遍性", + sheets_gid="1848560369", + sql_file="iframe_allow_directives.sql" + ) }} +
+
+ +有趣的是，第 11、12 和 13 位的移动端指令没有进入到上述名单，它们是 `vr`（占 6%），`payment`（占 2%），`web-share`（占 1%），它们也许说明了我们在虚拟现实（以及元宇宙，如果你愿意的话）、在线支付和金融科技行业中看到的日益增长的趋势。最后，这似乎表明了基于 web 共享得到了更好的支持，这可能是由于过去几年在家办公（指新冠疫情期间）的兴起。 + +### Iframe 沙盒（Iframe Sandbox） + +在网站中使用 iframe 元素是开发人员长期以来的做法，以便轻松嵌入第三方内容，如富媒体、跨应用组件，甚至是广告，有些人甚至会认为 iframe 元素在嵌入它们的网站和源网站之间形成了一个安全边界，但事实并非如此。 + +HTML `