diff --git a/src/config/last_updated.json b/src/config/last_updated.json index febc8ec70de..e28bfc9f64b 100644 --- a/src/config/last_updated.json +++ b/src/config/last_updated.json @@ -41,8 +41,8 @@ }, "/static/js/web-vitals.js": { "date_published": "2020-11-13T00:00:00.000Z", - "date_modified": "2024-06-10T00:00:00.000Z", - "hash": "fd1e29002e3518e8bf128dbbddaecc07" + "date_modified": "2024-06-21T00:00:00.000Z", + "hash": "0bf1a7e9889865e1cbbc6058659c9d83" }, "/static/js/webmentions.js": { "date_published": "2021-12-01T00:00:00.000Z", @@ -1778,6 +1778,11 @@ "date_modified": "2024-05-07T00:00:00.000Z", "hash": "025f7034129e8d56d6b4a7ee0d699762" }, + "ja/2022/chapters/security.html": { + "date_published": "2024-06-21T00:00:00.000Z", + "date_modified": "2024-06-21T00:00:00.000Z", + "hash": "805a470811f9e404912bac394555f032" + }, "ja/2022/chapters/seo.html": { "date_published": "2023-10-19T00:00:00.000Z", "date_modified": "2023-10-19T00:00:00.000Z", diff --git a/src/content/ja/2022/security.md b/src/content/ja/2022/security.md new file mode 100644 index 00000000000..48c5c7db0a3 --- /dev/null +++ b/src/content/ja/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 Almanacのセキュリティ章は、トランスポート層セキュリティ、コンテンツの組み込み（CSP、Feature Policy、SRI）、Web防衛メカニズム（XSS、XS-Leaksの対策）、およびセキュリティメカニズムの採用を推進する要因について取り上げています。 +authors: [SaptakS, lirantal, clarkio] +reviewers: [kushaldas, tunetheweb] +analysts: [VictorLeP, vikvanderlinden, GJFR] +editors: [tunetheweb] +translators: [ksakae1216] +SaptakS_bio: Saptak Sは、ウェブ開発における使いやすさ、セキュリティ、プライバシー、アクセシビリティを中心に据えた人権重視のウェブデベロッパーです。彼は、The A11Y Project、OnionShare、Wagtailなど、さまざまなオープンソースプロジェクトの貢献者兼メンテナです。彼のブログはsaptaks.blogで読むことができます。 +lirantal_bio: オープンソースおよびJavaScriptセキュリティの取り組みで知られるLiran Talは、受賞歴のあるソフトウェア開発者であり、セキュリティ研究者、そしてJavaScriptコミュニティでのオープンソースのチャンピオンです。彼は国際的に認められたGitHub Starであり、オープンソースへの支援で知られ、Node.jsのセキュリティに対する彼の功績でOpenJS FoundationからPathfinder for Securityを受賞しています。彼の開発者セキュリティ教育への貢献には、OWASPプロジェクトのリーダーシップ、サプライチェーンセキュリティツールの構築、CNCFおよびOpenSSFイニシアティブへの参加、そして「O'Reilly's Serverless Security」のような書籍の執筆が含まれます。彼はSnyk.ioでデベロッパーアドボカシーチームを率いており、より優れたアプリケーションセキュリティスキルで開発者を支援することを使命としています。 +clarkio_bio: Brianはアプリケーションセキュリティに関する深い経験を持つウェブデベロッパーです。彼はSnyk.ioのデベロッパーアドボケートとして、開発者が安全なウェブアプリケーションを構築できるよう支援しています。彼はフルスタックプロジェクト全般にわたる経験がありますが、とくにバックエンドサービス、API、および開発者ツールに焦点を当てています。Brianは、自身のキャリアを通じて得た成功と失敗から学んだことを開発者に教えることに情熱を注いでいます。彼の週間ライブストリームやPluralsightのコースのいずれかで、その活動を見ることができます。 +results: https://docs.google.com/spreadsheets/d/1cwJ43NL2IN2PxJa5oiOoJCRkSh566XE_k9uHnGJdWeg/ +featured_quote: 人々の個人情報や生活のさまざまな側面が日々デジタル化されているため、セキュリティとプライバシーの重要性はますます高まっています。ウェブサイトは、セキュリティのベストプラクティスを採用することで、ユーザーが保護されるようにする責任があります。 +featured_stat_1: +14% +featured_stat_label_1: Content Security Policy の採用増加 +featured_stat_2: 428 +featured_stat_label_2: `Clear-Site-Data` ヘッダーを使用するウェブサイト +featured_stat_3: +85% +featured_stat_label_3: Permissions Policy の採用増加 +--- + +## 序章 + +人々の個人情報がさらにデジタル化するにつれて、インターネット全体でセキュリティとプライバシーが非常に重要になっています。ウェブサイトのオーナーには、ユーザーから収集したデータを安全に保つ責任があります。そのため、ユーザーをマルウェアが悪用可能な脆弱性から保護するために、すべてのセキュリティベストプラクティスを採用することが不可欠です。 + +[過去の年同様](../2021/security)、私たちはウェブコミュニティによるセキュリティ方法とベストプラクティスの採用と使用を分析しました。私たちは、すべてのウェブサイトが採用すべき基本的なセキュリティ対策に関連する指標を分析しました。これには、[トランスポートセキュリティ](#トランスポートセキュリティ)や[適切なクッキー管理](#クッキー)などが含まれます。また、異なるセキュリティヘッダーの採用と、それらが[コンテンツの取り込み](#コンテンツの組み込み)や[さまざまな悪意のある攻撃の防止](#攻撃の予防)にどのように役立つかについても議論しました。 + +私たちは、[セキュリティ対策の採用](#セキュリティメカニズムの導入要因)を地域、技術スタック、ウェブサイトの人気度との相関関係を調べました。このような相関関係が、すべての技術スタックがデフォルトでより良いセキュリティ対策を目指すことを促進することを願っています。また、Web Application Security Working Groupの標準とドラフトに基づいて、脆弱性開示やその他のセキュリティ関連の設定を支援する[よく知られた URI](#よく知られたuri)についても議論します。 + +## トランスポートセキュリティ + +トランスポート層セキュリティは、ユーザーとウェブサイト間のデータとリソースの安全な通信を保証します。[HTTPS](https://developer.mozilla.org/ja/docs/Glossary/https)は、クライアントとサーバー間のすべての通信を暗号化するために[TLS](https://www.cloudflare.com/ja-jp/learning/ssl/transport-layer-security-tls/)を使用します。 + +{{ figure_markup( + content="94%", + caption="デスクトップでHTTPSを使用するリクエスト。", + classes="big-number", + sheets_gid="1093490384", + sql_file="https_request_over_time.sql", +) }} + +デスクトップでの総リクエストの94%、モバイルでの総リクエストの93%がHTTPS経由で行われています。すべての主要ブラウザーには、ウェブサイトがHTTPSではなくHTTPを使用している場合に警告を表示する[HTTPS-only モード](https://support.mozilla.org/ja/kb/https-only-prefs)があります。 + +{{ 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経由で提供されるホームページの割合は低いままです。なぜなら、ウェブサイトへの多くのリクエストがフォントやCDNなどの[サードパーティ](./third-parties)サービスによって占められており、これらはHTTPS採用率が高いからです。昨年に比べてHTTPS経由で提供されるホームページの割合はわずかに増加しています。デスクトップでは昨年の84.3%から89.3%に、モバイルでは昨年の81.2%から85.5%に増加しています。 + +### プロトコルバージョン + +HTTPSを使用するだけでなく、最新のTLSバージョンを使用することも重要です。[TLSワーキンググループ](https://datatracker.ietf.org/doc/rfc8996/)は、複数の弱点があったため、TLS v1.0およびv1.1を非推奨としました。昨年の章以降、Firefoxは[UIを更新](https://support.mozilla.org/ja/kb/secure-connection-failed-error-message#w_an-quan-najie-sok-gadekimasendeshita)し、Firefoxバージョン97のエラーページからTLS 1.0と1.1を有効にするオプションが削除されました。Chromeもバージョン98以降、TLS 1.0と1.1のエラーページのバイパスを[許可しなくなりました](https://chromestatus.com/feature/5759116003770368)。 + +TLS v1.3は最新のバージョンで、2018年8月にIETFによってリリースされました。TLS v1.3は[TLS v1.2よりもはるかに高速で、より安全です](https://www.cloudflare.com/ja-jp/learning/ssl/why-use-tls-1.3/)。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への一定のシフトが見られます。 + +### 暗号スイート + +[暗号スイート](https://learn.microsoft.com/ja-jp/windows/win32/secauthn/cipher-suites-in-schannel)は、クライアントとサーバーがTLSを使用して安全に通信を開始する前に合意する必要がある暗号化アルゴリズムのセットです。 + +{{ figure_markup( + image="distribution-of-cipher-suites.png", + caption="暗号スイートの分布。", + description="デバイスごとに使用される暗号スイートを示す積み上げバーチャート。`AES_128_GCM`がもっとも一般的で、デスクトップとモバイルサイトの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://ja.wikipedia.org/wiki/Galois/Counter_Mode)暗号モードは、[パディング攻撃](https://blog.qualys.com/product-tech/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities)に弱くないため、はるかに安全とされています。TLS v1.3は[モダンなブロック暗号モードのみをサポートしており](https://datatracker.ietf.org/doc/html/rfc8446#page-133)、より安全です。また、[暗号スイートの順序付けの問題も解消しています](https://go.dev/blog/tls-cipher-suites)。暗号と復号に使用される鍵のサイズも暗号スイートの使用を決定する要因の1つです。依然として128ビット鍵サイズが広く使用されているため、昨年のグラフと大きな違いは見られません。`AES_128_GCM`が依然としてもっとも使用されている暗号スイートで、使用率は79%です。 + +{{ figure_markup( + image="forward-secrecy-support.png", + caption="フォワードシークレシーの使用。", + 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://ja.wikipedia.org/wiki/Forward_secrecy)を義務付けています。モバイルとデスクトップのリクエストの97%でフォワードシークレシーが使用されています。 + +### 証明書認証局 + +[証明書認証局](https://www.ssl.com/faqs/what-is-a-certificate-authority/)（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="ウェブサイトのトップ10証明書発行者。", sheets_gid="1306037372", sql_file="tls_ca_issuers_pages.sql") }}
+
+ +[R3（Let's Encrypt）](https://letsencrypt.org/)は、デスクトップのウェブサイトの48%、モバイルのウェブサイトの52%が彼らによって発行された証明書を使用しており、引き続きチャートをリードしています。非営利組織であるLet's EncryptはHTTPSの採用に重要な役割を果たしており、引き続き[多くの証明書を発行しています](https://letsencrypt.org/stats/#daily-issuance)。また、残念ながら最近亡くなったその創設者の一人、[Peter Eckersly](https://community.letsencrypt.org/t/peter-eckersley-may-his-memory-be-a-blessing/183854)を記念する瞬間を持ちたいと思います。 + +[Cloudflare](https://developers.cloudflare.com/ssl/ssl-tls/certificate-authorities/)も、顧客に無料で証明書を提供することで2位を維持しています。CloudflareのCDNは、RSA証明書よりも小さく効率的な[楕円曲線暗号（ECC）](https://www.digicert.com/faq/ecc.htm)証明書の使用を増やしていますが、古いクライアントに非ECC証明書も提供する必要があるため、展開が困難なことが多いです。Let's EncryptとCloudflareの割合が増加するにつれて、他のCAの使用率が少し減少しているのが見られます。 + +### HTTP Strict Transport Security + +[HTTP Strict Transport Security (HSTS)](https://developer.mozilla.org/ja/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`の3つの異なるディレクティブを持つことができます。`max-age`はブラウザがサイトにHTTPSを使用してのみアクセスすることを覚えておくべき時間（秒単位）を示すのに役立ちます。`max-age`はヘッダーに必須のディレクティブです。 + +{{ figure_markup( + image="hsts-directives-usage.png", + caption="異なるHSTSディレクティブの使用。", + description="異なるHSTSディレクティブの使用率を示すバーチャート。`preload`はモバイルとデスクトップの両方でウェブサイトの19%で使用されています。`includeSubdomain`はデスクトップのウェブサイトの37%、モバイルのウェブサイトの34%で使用されています。`max-age`が0のものは、デスクトップのウェブサイトの6%、モバイルのウェブサイトの5%で使用されています。有効な`max-age`は、デスクトップのウェブサイトの94%、モバイルのウェブサイトの95%で使用されています。", + 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`を含んでいます。HSTS仕様の一部ではない[`preload`ディレクティブ](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Strict-Transport-Security#preloading_strict_transport_security)を含むレスポンスは少なく、少なくとも31,536,000秒（または1年）の`max-age`と`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日です。[hstspreload.org](https://hstspreload.org/)は、HSTSヘッダーが適切に設定されて問題がないことが確認された場合、`max-age`を2年間に設定することを推奨しています。 + +## クッキー + +[HTTPクッキー](https://developer.mozilla.org/ja/docs/Web/HTTP/Cookies)は、サーバーがブラウザに送信するユーザーに関するデータのセットです。クッキーは、セッション管理、パーソナライゼーション、追跡、その他のユーザーに関連する状態情報を異なるリクエストに渡って使用できます。 + +クッキーが適切に設定されていない場合、[セッションハイジャック](https://owasp.org/www-community/attacks/Session_hijacking_attack)、[クロスサイトリクエストフォージェリ(CSRF)](https://owasp.org/www-community/attacks/csrf)、[クロスサイトスクリプトインクルージョン(XSSI)](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/11-Client_Side_Testing/13-Testing_for_Cross_Site_Script_Inclusion)、その他の[クロスサイトリーク](https://xsleaks.dev/)の脆弱性など、多くの異なる形態の攻撃に対して脆弱になる可能性があります。 + +### Cookie属性 + +上記の脅威に対抗するために、開発者はクッキーに3つの異なる属性を使用できます：`HttpOnly`、`Secure`、そして`SameSite`です。`Secure`属性は`HSTS`ヘッダーと同様で、クッキーが常にHTTPS経由で送信されることを保証し、[Manipulator in the Middle攻撃](https://owasp.org/www-community/attacks/Manipulator-in-the-middle_attack)を防ぎます。`HttpOnly`は、クッキーがJavaScriptコードからアクセスできないようにすることで、[クロスサイトスクリプティング攻撃](https://owasp.org/www-community/attacks/xss/)を防ぎます。 + +{{ figure_markup( + image="httponly-secure-samesite-cookie-usage.png", + caption="クッキー属性（デスクトップ）。", + description="デスクトップサイトで使用されるクッキー属性の棒グラフで、ファーストパーティとサードパーティのクッキーに分けて表示されています。ファーストパーティでは、`HttpOnly`が36%、`Secure`が37%、`SameSite`が45%で使用されており、サードパーティでは、`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種類があります。ファーストパーティのクッキーは通常、訪問している直接のサーバーによって設定されます。サードパーティのクッキーはサードパーティのサービスによって作成され、しばしばトラッキングや広告配信に使用されます。デスクトップでのファーストパーティクッキーの37%に`Secure`があり、36%に`HttpOnly`が設定されています。しかし、サードパーティクッキーでは、クッキーの90%に`Secure`があり、21%に`HttpOnly`が設定されています。サードパーティのクッキーでは`HttpOnly`の割合が少ないのは、JavaScriptコードによるアクセスを許可したいためです。 + +{{ figure_markup( + image="samesite-cookie-attributes.png", + caption="Same site cookie属性。", + description="ファーストパーティとサードパーティで分けたSameSiteクッキー属性の棒グラフ。ファーストパーティでは`SameSite=lax`が61%、`SameSite=strict`が2%、`SameSite=none`が37%で使用されています。サードパーティでは`SameSite=lax`が1%、`SameSite=strict`が1%、`SameSite=none`が98%で使用されています。", + 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攻撃を防ぐために使用できます。`Strict`値はクッキーが元々のサイトからのみ送信されることを許可し、`Lax`値はユーザーがリンクをたどって元のサイトにナビゲートする場合にのみ、クロスサイトリクエストにクッキーを送信することを許可します。`None`値の場合、クッキーは発信元とクロスサイトのリクエストの両方に送信されます。`SameSite=None`が設定されている場合、クッキーの`Secure`属性も設定されている必要があります（そうでない場合、クッキーはブロックされます）。`SameSite`属性を持つファーストパーティクッキーの61%が`Lax`値を持っています。`SameSite`属性がない場合、ほとんどのブラウザはデフォルトで`SameSite=Lax`を使用するため、これがチャートを支配し続けるのを見ています。サードパーティのクッキーでは、`SameSite=None`がデスクトップでのクッキーの98%で非常に高いままです。これは、サードパーティのクッキーがクロスサイトリクエストで送信されたいと考えているためです。 + +### Cookieの寿命 + +クッキーが削除されるタイミングを設定するには、`Max-Age`と`Expires`の2つの方法があります。`Expires`はクライアントに関連する特定の日付を使用してクッキーが削除されるタイミングを決定し、`Max-Age`は秒単位の期間を使用します。 + +{{ figure_markup( + image="cookie-age-usage-by-site-in-desktop-in-days.png", + caption="デスクトップでのCookieの寿命の使用（日数）。", + description="クッキーの寿命を日数で示すパーセンタイルの棒グラフ。10パーセンタイルでは`Max-Age`が1で、`Expires`が10で、実際の最大寿命は7です。25パーセンタイルでは`Max-Age`と`Expires`がそれぞれ90日と60日で、実際の寿命は60日です。50パーセンタイルでは`Max-Age`、`Expires`、実際の寿命が365日です。75パーセンタイルでも同様に365日です。90パーセンタイルでは`Max-Age`、`Expires`、実際の寿命が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日です。したがって、今年は実際の最大寿命の中央値が180日から365日に上がりました。`Max-Age`が729日で`Expires`が730日の90パーセンタイルにもかかわらず、Chromeは`Max-Age`と`Expires`の両方に[400日の上限を設定する予定](https://chromestatus.com/feature/4887741241229312)です。 + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
%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="デスクトップでもっとも一般的なクッキーの有効期限の値。", + 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="モバイルでもっとも一般的なクッキーの有効期限の値。", + sheets_gid="707972861", + sql_file="cookie_max_age_expires_top_values.sql", + ) }} +
+
+ +もっとも一般的な`Expires`には興味深い値があります。デスクトップでもっとも使用されている`Expires`値は「1970年1月1日00:00:00 GMT」です。クッキーの`Expires`値が過去の日付に設定されると、クッキーはブラウザから削除されます。1970年1月1日00:00:00 GMTはUnixエポックタイムであり、クッキーを期限切れにするか削除するためによく使用されます。 + +## コンテンツの組み込み + +ウェブサイトのコンテンツは多様な形を取り、CSS、JavaScript、フォントや画像などのメディア資産といったリソースが必要とされます。これらは通常、コンテンツ配信を効率化するために、クラウドネイティブインフラのリモートストレージサービスやコンテンツ配信ネットワーク（CDN）からロードされます。 + +しかし、ウェブサイトに組み込むコンテンツが改ざんされていないことを保証することは非常に重要であり、その影響は壊滅的なものになる可能性があります。とくに最近ではサプライチェーンのセキュリティへの意識が高まり、[Magecart攻撃](https://www.imperva.com/learn/application-security/magecart/)など、ウェブサイトのコンテンツシステムを狙った横断的なマルウェアの注入を通じて、クロスサイトスクリプティング（XSS）の脆弱性などを利用する事例が増加しているため、コンテンツの組み込みはさらに重要になっています。 + +### コンテンツセキュリティポリシー + +コンテンツの組み込みに関連するセキュリティリスクを軽減するための効果的な手段として、コンテンツセキュリティポリシー（CSP）を採用できます。これは、クロスサイトスクリプティングによるコード注入やクリックジャッキングなどの攻撃を軽減するために、防御の深さを増すセキュリティ標準です。 + +これは、事前に定義された信頼できるコンテンツルールのセットが遵守され、制限されたコンテンツのバイパスや組み込みの試みが拒否されることを保証することで機能します。たとえば、ブラウザで実行されるJavaScriptコードを、それが提供された同一のオリジンとGoogle Analyticsからのみ許可するコンテンツセキュリティポリシーは、`script-src 'self' www.google-analytics.com;`として定義されます。``のようなクロスサイトスクリプティング注入の試みは、設定されたポリシーを強制するブラウザによって拒否されます。 + +{{ figure_markup( + caption="2021年からのContent-Security-Policyヘッダーの採用率の相対的な増加。", + content="+14%", + classes="big-number", + sheets_gid="1799124531", + sql_file="security_headers_prevalence.sql" +) +}} + +2021年のデータの12.8%から2022年のデータの14.6%へと、`Content-Security-Policy`ヘッダーの採用率が14%相対的に増加しています。これは開発者とウェブセキュリティコミュニティの間で採用傾向が高まっていることを示しています。これはポジティブな兆候ですが、依然としてこのより高度な機能を使用しているサイトは少数派です。 + +CSPは、HTMLレスポンス自体に提供される場合にもっとも有効です。ここでは、2年前に7.2%、昨年に9.3%、今年にはモバイルホームページの合計11.2%でCSPヘッダーが提供されていることから、採用が着実に増加していることがわかります。 + +{{ 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リクエストの四分の一以上で提供されている上位3つの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リクエストの高い採用が事実上の標準となっていることに起因する可能性があります。ただし、この日付時点で`block-all-mixed-content`が非推奨とされているにもかかわらず、高い採用率を示しています。これは、CSP仕様が急速に進化しており、ユーザーが最新の状態に追いつくのが困難であることを示しているかもしれません。 + +クロスサイトスクリプティング攻撃の軽減に関連して、Googleのセキュリティイニシアチブである[Trusted Types](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Content-Security-Policy/trusted-types)があります。これはDOMインジェクションクラスの脆弱性を防ぐための手法を採用するために、ネイティブブラウザAPIのサポートが必要です。これはGoogleエンジニアによって積極的に提唱されていますが、まだW3Cで[ドラフト提案](https://w3c.github.io/trusted-types/dist/spec/)の段階にあります。それでも、リクエストの0.1%で関連するCSPセキュリティヘッダー`require-trusted-types-for`および`trusted-types`が記録されています、これは多くはありませんが、採用の成長傾向を示しているかもしれません。 + +定義済みのルールセットからのCSP違反が発生しているかどうかを評価するために、ウェブサイトは`report-uri`ディレクティブを設定できます。このディレクティブでは、ブラウザがJSON形式のデータをHTTP POSTリクエストとして送信します。`report-uri`リクエストはCSPヘッダーを持つすべてのデスクトップトラフィックの4.3%を占めていますが、現在は非推奨のディレクティブであり、`report-to`に置き換えられており、デスクトップリクエストの1.8%を占めています。 + +厳密なコンテンツセキュリティポリシーを実装する上での最大の課題の1つは、イベントハンドラーやDOMの他の部分に一般的に設定されるインラインJavaScriptコードの存在です。チームがCSPセキュリティ標準を段階的に採用できるようにするために、ポリシーは`unsafe-inline`または`unsafe-eval`を`script-src`ディレクティブのキーワード値として設定することがあります。これにより、一部のクロスサイトスクリプティング攻撃ベクトルを防ぐことができず、ポリシーの予防措置として逆効果になります。 + +チームは、インラインJavaScriptコードにノンスまたはSHA256ハッシュを使用して署名することで、より安全な態勢を取ることができます。これは次のような形式になります： + +``` +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` の使用状況を示す縦棒グラフ。モバイルのCSPヘッダーを持つウェブサイトの12%、デスクトップの14%で `nonce-` が使用されています。`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リクエストの統計によると、`script-src` 値の94%で `unsafe-inline`、80%で `unsafe-eval` が存在します。これは、ウェブサイトのアプリケーションコードをロックダウンし、インラインJavaScriptコードを避けることの実際の課題を示しています。さらに、上述のリクエストのうち14%だけが、安全でないインラインJavaScriptコードの使用を保護するのに役立つ `nonce-` ディレクティブを採用しています。 + +コンテンツセキュリティポリシーの定義の高い複雑さを示すかもしれないのが、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;` の値に設定されています。これは、もっとも一般的なCSPディレクティブの上位3つを組み合わせたものです。 + +コンテンツセキュリティポリシーは、しばしばフォント、広告関連のスクリプト、一般的なコンテンツ配信ネットワークの使用をサポートするために、自身の起源以外のコンテンツを許可する必要があります。そのため、リクエスト全体でもっとも一般的な起源のトップ10は次のとおりです： + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
発行者デスクトップモバイル
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（Content Security Policy）セキュリティ標準は、Webブラウザだけでなく、コンテンツ配信ネットワークやコンテンツ管理システムにも広くサポートされており、Webセキュリティの脆弱性を防御するためのウェブサイトやWebアプリケーションに強く推奨されるツールです。 + +### サブリソースインテグリティ + +もう1つの防御の深さを提供するツールは、サブリソースインテグリティであり、コンテンツの改ざんに対するウェブセキュリティ防御層を提供します。コンテンツセキュリティポリシーがどの種類やソースのコンテンツが許可されるかを定義する一方で、サブリソースインテグリティメカニズムは、そのコンテンツが悪意のある目的で変更されていないことを保証します。 + +サブリソースインテグリティを使用する参考事例は、サードパーティのパッケージマネージャーからJavaScriptコンテンツをロードする場合です。これらの例には、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つに1つ（20％）がサブリソースインテグリティを採用しています。これらのうち、83％がデスクトップの ` +``` + +{{ figure_markup( + image="sri-hash-function-usage.png", + caption="SRIハッシュ機能", + description="さまざまなハッシュ機能を使用するSRI要素の割合を示す棒グラフ。デスクトップウェブサイトのSRI要素の58.4％およびモバイルウェブサイトのSRI要素の60.7％でSHA-384が使用されています。デスクトップウェブサイトのSRI要素の32.4％およびモバイルウェブサイトのSRI要素の30.8％でSHA-256が使用されています。デスクトップウェブサイトのSRI要素の10.9％およびモバイルウェブサイトのSRI要素の9.9％で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ハッシュタイプを示しています。 + +CDNはサブリソースインテグリティに慣れており、ページ上で提供されるコンテンツのURL参照にサブリソースインテグリティ値を含むことで、消費者に安全なデフォルトを提供しています。 + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ホストデスクトップモバイル
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のホストのランキングを上回ったことです。 + +### パーミッションポリシー + +時間とともにブラウザはますます強力になり、ウェブサイトに利用可能なさまざまなハードウェアや機能セットをアクセスして制御するためのより多くのネイティブAPIが追加されています。これらは、マイクをオンにしてデータを収集する悪意のあるスクリプトや、デバイスのジオロケーションを指紋認証して位置情報を収集するなど、特定の機能の悪用を通じてユーザーに潜在的なセキュリティリスクをもたらす可能性があります。 + +以前は `Feature-Policy` として知られ、現在は `Permissions-Policy` と名付けられているこのAPIは、ブラウザがアクセス可能な多くの機能の許可リストと拒否リストを制御するための実験的なブラウザAPIです。 + +`Permissions-Policy` の使用とHTTPS対応接続（97%）、`X-Content-Type-Options`（82%）、および `X-Frame-Options`（78%）との間に高い相関関係が見られます。すべての相関関係はデスクトップリクエストにわたっています。もう1つの高い相関関係は、特定の技術の交差点で観察され、Google My Businessモバイルページ（99%）と、次に近いAcquiaのCloud Platform（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パーセントポイントの僅かな増加を示しており、これはユーザーがウェブブラウザの仕様変更に追いついていることを示しています。 + +HTTPヘッダーとして使用されるだけでなく、この機能は以下のように ` +``` + +モバイルの1,150万フレームのうち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="iframeの`allow`ディレクティブの普及率。", + sheets_gid="1848560369", + sql_file="iframe_allow_directives.sql" + ) }} +
+
+ +興味深いことに、上記のリストに入っていない11位、12位、13位のモバイル用`allow`ディレクティブは、それぞれ`vr`（6%）、`payment`（2%）、`web-share`（1%）です。これらは、仮想現実（メタバースとも言われます）、オンライン決済、フィンテック業界を取り巻く業界の成長傾向を示唆しているかもしれません。最後に、これは過去数年の在宅勤務の習慣の増加により、Webベースの共有のサポートが向上していることを示していると考えられます。 + +### Iframeサンドボックス + +ウェブサイトで`iframe`要素を使用することは、リッチメディア、クロスアプリケーションコンポーネント、広告などのサードパーティコンテンツを簡単に埋め込むために、開発者が長年にわたって行ってきた実践です。一部の人々は、`iframe`要素が埋め込んでいるウェブサイトとソースウェブサイトの間にセキュリティ境界を形成すると考えるかもしれませんが、それは正確ではありません。 + +HTMLの`