部 II 章 12

セキュリティ

公開日：2022/03/20

更新日：2024/11/16

Hero image of Web Almanac characters padlocking a web page, while other Web Almanac characters subdue a masked thief who has a set of bolt cutters.

Saptak Sengupta、 Tom Van Goethem と Nurullah Demir によって書かれた。

Caleb Queern、 Edmond W. W. Chan と Matteo Große-Kampmann によってレビュ。

Gertjan Franken による分析。

Barry Pollard 編集。

Sakae Kotaro によって翻訳された。

序章

現代はどんどんデジタル化が進んでいます。ビジネスだけでなく、私生活もデジタル化されています。私たちはオンラインで人と連絡を取り、メッセージを送り、友人と瞬間を共有し、ビジネスを行い日常生活を整理しています。同時に、この変化は、より多くの重要なデータがデジタル化され、私的、商業的にも処理されるようになったことを意味します。このような状況において、ユーザーデータの可用性、完全性、機密性を提供することでユーザーを保護することを目的とするサイバーセキュリティの重要性も増してきています。今日の技術に目を向けると、デジタルで提供されるソリューションを提供するために、ウェブリソースがますます利用されていることがわかります。それはまた、その普及により、私たちの現代生活とWebアプリケーションのセキュリティとの間に強い結びつきがあることを意味します。

この章では、Web上のセキュリティの現状を分析し、Webコミュニティが自分たちの環境を守るために使っている（そして見逃している）手法の概要を説明します。具体的には、このレポートでは、一般的な実装、プロトコルのバージョン、暗号スイートなどのトランスポートレイヤーセキュリティ (HTTPS) に関するさまざまな指標を分析しています。また、クッキーを保護するための技術についても概観しています。そして、コンテンツ・インクルージョンの話題と攻撃を阻止するための方法（例：特定のセキュリティヘッダーの使用）についての包括的な分析が掲載されています。また、セキュリティメカニズムがどのように採用されているか（国別や特定の技術別など）についても見ています。また、Cryptojackingのようなウェブ上の不正行為について議論し、最後にsecurity.txt URL の使用について見ています。

分析対象ページをデスクトップとモバイルの両方でクロールしていますが、多くのデータで同様の結果が得られているため、本章で紹介する統計情報は、とくに断りのない限り、モバイルページのセットを参照しています。データの収集方法の詳細については、方法論ページを参照してください。

トランスポートセキュリティ

最近の傾向として、今年もHTTPSを採用するWebサイトの数が継続的に増加していると思われます。トランスポート・レイヤー・セキュリティは、Webサイトの安全な閲覧を可能にするため重要であり、利用者に提供されるリソースやWebサイトに送信されるデータが転送中に改ざんされないことを保証するものです。現在、主要なブラウザのほとんどにHTTPS専用の設定があり、ウェブサイトがHTTPSではなくHTTPを使用している場合は、ユーザーに警告が表示されるようになっているため、より広範な導入が進んでいます。

91.1%

図12.1. モバイルでHTTPSを使用するリクエストの割合です。

現在、デスクトップではウェブサイトへの総リクエストの91.9%、モバイルでは91.1%がHTTPSで提供されていることがわかります。Let’s Encryptのような非営利の認証局のおかげで、増え続ける証明書が日々発行されているのを目にします。

現在、デスクトップで84.3%、モバイルでは81.2%のWebサイトのホームページがHTTPSで提供されているため、HTTPSを利用しているWebサイトとHTTPSを利用しているリクエストの間にはまだギャップがあると考えられます。これは、HTTPSリクエストの印象的な割合の多くは、フォント、分析、CDNなどのサードパーティサービスによって占められており、最初のウェブページ自体ではないことが多いからです。

HTTPSを使用しているサイトは継続的に改善しています（昨年から約7-8% の増加）。しかし、ブラウザがデフォルトでHTTPS専用モードを採用し始めると、まもなく多くのメンテナンスされていないウェブサイトが警告を表示し始めるかもしれません。

プロトコルのバージョン

トランスポートレイヤーセキュリティ（TLS）とは、HTTPリクエストを安全かつプライベートにするためのプロトコルです。時代とともに、TLSには新たな脆弱性が発見され、修正されています。したがって、ウェブサイトをHTTPSで提供するだけでなく、そのような脆弱性を回避するために最新のTLS設定が使用されていることを確認することが重要です。

その一環として、最新バージョンの採用によるセキュリティと信頼性の向上を目指し、2021年3月25日をもってTLS 1.0および1.1がインターネット技術タスクフォース（IETF）により非推奨とされました。また、すべてのアップストリームブラウザは、TLS 1.0および1.1のサポートを完全に削除するか、非推奨としています。たとえば、FirefoxはTLS1.0と1.1を非推奨としていますが、完全に削除していません。これは、パンデミックの間、ユーザーが、しばしばまだTLS1.0で動いている政府のウェブサイトにアクセスする可能性があるからです。ユーザーは、ブラウザの設定で security.tls.version.min を変更し、ブラウザが許可するもっとも低いTLSバージョンを決定することもできます。

デスクトップで60.4%、モバイルでは62.1%のページがTLSv1.3を使用しており、TLSv1.2を超えるプロトコルバージョンが主流となっています。TLSv1.3を使用しているページ数は、それぞれ43.2%、45.4%であった昨年から約20%増加しました。

暗号スイート

暗号スイートは、TLSで使用されるアルゴリズムのセットで、安全な接続を行うために使用されます。現代のガロアカウンターモード (GCM) 暗号モードは、古い Cipher Block Chaining Mode (CBC) と比較して、はるかに安全であると考えられています。暗号は、パディング攻撃に対して脆弱であることが示されています。TLSv1.2は新しい暗号スイートと古い暗号スイートの両方をサポートしていましたが、TLSv1.3は古い暗号スイートを一切サポートしていません。これが、TLSv1.3がより安全な接続オプションである理由の1つです。

96.8%

図12.4. フォワードセキュリティーを利用したモバイルサイト。

最近の暗号スイートはほとんどすべてフォワードセキュリティー鍵交換をサポートしています。つまり、サーバーの鍵が漏洩した場合、その鍵を使った古いトラフィックは復号化できないのです。デスクトップで96.6%、モバイルでは96.8%が前方秘匿を使用しています。TLSv1.2ではオプションだったフォワードセキュリティーが、TLSv1.3では必須となったことも、より安全である理由の1つです。

暗号モードとは別に考慮すべきは、認証された暗号化および認証された復号化アルゴリズムの鍵のサイズです。鍵のサイズが大きいと、暗号化するのに時間がかかり、接続の暗号化と復号化のための集中的な計算が、サイトのパフォーマンスにほとんど影響を与えません。

AES_128_GCMは、デスクトップで79.4％、モバイルで78.9％と、依然としてもっとも広く利用されている暗号スイートです。AES_128_GCMは、暗号化と復号化にキーサイズ128ビットのAdvanced Encryption Standard (AES) とGCM暗号モードを使用することを表しています。128ビットの鍵はまだ安全だと考えられていますが、ブルートフォース攻撃により長く耐えられるように、256ビットの鍵が徐々に業界標準になりつつあります。

認証局

認証局とは、デジタル証明書を発行する企業や組織のことで、WebサイトなどWeb上のエンティティの所有権や身元を検証するのに役立っています。認証局は、ブラウザが認識するTLS証明書を発行し、ウェブサイトがHTTPSで提供できるようにするため必要です。昨年と同様に、サードパーティのサービスやリソースではなく、Webサイト自身が使用する認証局について再び調べます。

発行者	アルゴリズム	デスクトップ	モバイル
R3	RSA	46.9%	49.2%
Cloudflare Inc ECC CA-3	ECDSA	11.7%	11.5%
Sectigo RSA Domain Validation Secure Server CA	RSA	8.3%	8.2%
cPanel, Inc. Certification Authority	RSA	5.0%	5.5%
Go Daddy Secure Certificate Authority - G2	RSA	3.6%	3.0%
Amazon	RSA	3.4%	3.0%
Encryption Everywhere DV TLS CA - G1	RSA	1.3%	1.6%
AlphaSSL CA - SHA256 - G2	RSA	1.2%	1.2%
RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1	RSA	1.2%	1.1%
DigiCert SHA2 Secure Server CA	RSA	1.1%	0.9%

図12.6. Webサイト向け証明書発行会社トップ10

Let’s Encryptは、新しい証明書のバイト数を節約するために、その主題のコモンネームを “Let’s Encrypt Authority X3” から単に “R3” に変更しました。つまり、R3が署名したSSL証明書は、Let’s Encryptが発行していることになるのです。このように、Let’s Encryptが発行する証明書を使用しているデスクトップWebサイトは46.9%、モバイルサイトでは49.2%と、例年通りLet’s Encryptがチャートをリードしていることがわかります。これは昨年より2〜3％増加している。Let’s Encryptの無料証明書自動生成機能は、誰もが簡単にHTTPSでウェブサイトを提供できるようにする上で、画期的な役割を果たしています。

Cloudflareは、同様に顧客向けに無料の証明書を提供しており、引き続き2位を維持しています。また、Cloudflare CDNは、Elliptic Curve Cryptography（ECC）証明書の利用を増やしています。RSA証明書よりも小型で効率的ですが、古いクライアントに対して非ECC証明書も提供し続ける必要があり、しばしば導入が困難となります。CloudflareのようなCDNを利用することで、その複雑さを解消できます。最新のブラウザはすべてECC証明書に対応していますが、Chromeなど一部のブラウザはOSに依存しています。そのため、Windows XPなどの古いOSでChromeを使う人は、ECC以外の証明書にフォールバックする必要があるのです。

HTTPストリクトトランスポートセキュリティ

HTTPストリクトトランスポートセキュリティ (HSTS)は、ウェブサイトとの通信に安全なHTTPS接続を常に使用するようブラウザに指示する応答ヘッダーです。

22.2%

図12.7. モバイルでHSTSヘッダーを持つリクエストの割合です。

Strict-Transport-Security ヘッダーは、そのサイトへのリクエストが行われる前に、http:// URLを https:// URLへ変換するのに役立つものです。モバイル用レスポンスの22.2%、デスクトップ用レスポンスの23.9%にHSTSヘッダーがあります。

HSTSディレクティブ	デスクトップ	モバイル
Valid `max-age`	92.7%	93.4%
`includeSubdomains`	34.5%	33.3%
`preload`	17.6%	18.0%

図12.8. HSTSディレクティブの使用方法。

HSTSヘッダーを持つサイトのうち、デスクトップで92.7%、モバイルでは93.4%が有効なmax-age（つまり、値がゼロでなく、空でないこと）を持ち、ブラウザは何秒間だけHTTPSでウェブサイトにアクセスすべきか判断しています。

モバイルで33.3%、デスクトップでは34.5%のリクエストレスポンスがHSTS設定にincludeSubdomainを含んでいます。preload ディレクティブは HSTS仕様の一部ではないため、レスポンス数が少なくなっています。また、最低でも max-age が31,536,000秒（または1年）で、さらに includeSubdomain ディレクティブも必要なため、このディレクティブは存在します。

すべてのリクエストに対するHSTS max-age の値（日数単位）。 — 図12.9. すべてのリクエストに対するHSTS `max-age` の値（日数単位）。

HSTSヘッダーのmax-age属性の中央値は、モバイルとデスクトップの両方で365日であることがわかりました。https://hstspreload.org/ では、HSTSヘッダーが適切に設定され問題が、発生しないことが確認された場合、max-ageを2年間とすることを推奨しています。

クッキー

HTTPクッキーとは、サーバーがウェブブラウザに送信する、ウェブサイトにアクセスするユーザーに関する小さな情報のことです。ブラウザはこの情報を保存し、その後のサーバーへのリクエストで送り返します。クッキーは、セッション管理に役立ち、ユーザーが現在ログインしているかどうかなど、ユーザーの状態情報を維持します。

Cookieを適切に保護しないと、攻撃者はセッションを乗っ取り、ユーザーになりすましてサーバーに不要な変更を送ることができます。また、クロスサイトリクエストフォージェリ という攻撃にもつながり、ユーザーのブラウザがユーザーに気づかれないように、クッキーを含むリクエストを不用意に送信してしまうことがあるのです。

他にも、クロスサイトスクリプトインクルージョン (XSSI) や XS-リークス の脆弱性クラスのさまざまなテクニックなど、クロスサイトのリクエストにクッキーを含めることに依存しているタイプの攻撃もいくつか存在します。

特定の属性や接頭辞を追加することで、クッキーが安全に送信され、意図しない相手やスクリプトによってアクセスされないようにできます。

`Secure`

Secure 属性が設定されたクッキーは、安全なHTTPS接続でのみ送信され、Manipulator-in-the-middle 攻撃で盗まれないようにします。HSTSと同様に、TLSプロトコルが提供するセキュリティの強化にも貢献します。ファーストパーティのクッキーについては、デスクトップとモバイルの両方で、30%強のクッキーに Secure 属性が設定されています。しかし、デスクトップにおけるサードパーティ製クッキーのうち、Secure属性を持つものの割合が、昨年の35.2％から今年は67.0％に大きく増加していることがわかります。この増加は、後述する SameSite=none のクッキーに対して Secure 属性が必須であることに起因すると思われます。

`HttpOnly`

HttpOnly 属性が設定されたクッキーは、JavaScriptの document.cookie APIを使ってアクセスすることができません。このようなクッキーはサーバにのみ送ることができ、クッキーを悪用したクライアントサイドの クロスサイトスクリプティング (XSS) 攻撃を緩和するのに役立ちます。サーバーサイドのセッションにのみ必要なクッキーに使用されます。HttpOnly属性を持つクッキーの割合は、他のクッキー属性がそれぞれ32.7%と20.0%で使用されているのに比べ、ファーストパーティークッキーとサードパーティーの差はより小さくなっています。

`SameSite`

クッキーの SameSite 属性により、ウェブサイトはクロスサイトリクエストでクッキーを送信するタイミングとその有無をブラウザに通知できます。これはクロスサイトリクエストフォージェリ攻撃を防ぐために使用されます。SameSite=Strictはクッキーをそれが発生したサイトのみに送信することを可能にします。SameSite=Laxでは、ユーザーがリンクをたどって元のサイトに移動していない限り、クッキーはクロスサイトリクエストに送られません。SameSite=Noneでは、クッキーはオリジンサイトとクロスサイトリクエストの両方で送信されます。

SameSite 属性を持つファーストパーティークッキーの58.5%が Lax に設定されていることがわかります。一方、SameSite 属性が none に設定されているクッキーがまだ39.1% あり、かなり大変ですが、数は着実に減少しています。現在のほぼすべてのブラウザは、SameSite属性が設定されていない場合、SameSite=Laxをデフォルトとしています。ファーストパーティークッキー全体の約65%は SameSite 属性を持っていません。

プレフィックス

クッキープレフィックス __Host- と __Secure- は、セッションフィクスチャ攻撃のためにセッションクッキーの情報を上書きする攻撃を軽減するのに役立ちます。__Host- はクッキーをドメインロックするのに役立ちます。クッキーは Secure 属性と Path 属性を / に設定し、 Domain 属性を持たず、安全な場所から送信される必要があります。一方、__Secure-はクッキーが Secure 属性のみを持ち、安全な場所から送信されることを要求します。

クッキーの種類	`__Secure`	`__Host`
ファーストパーティ	0.02%	0.01%
サードパーティ	< 0.01%	0.03%

図12.11. モバイルでの __Secure と __Host の Cookieプレフィックスの使用について。

どちらの接頭辞もクッキーのかなり低い割合で使われていますが、__Secure-は前提条件が低いため、ファーストパーティークッキーでより一般的に見られます。

クッキー寿命

永続的なクッキーは、Expires属性で指定された日付、またはMax-Age属性で指定された期間の経過後に削除されます。Expires と Max-Age の両方が設定されている場合、 Max-Age が優先されます。

Max-Age を持つクッキーの約20.5%が31,536,000という値を持っていることから、中央値の Max-Age は365日であることがわかります。しかし、ファーストパーティークッキーの64.2%は Expiresを持ち、23.3%は Max-Age を持ちます。クッキーの間ではExpiresがずっと優勢なので、実際の最大寿命の中央値は、期待されるようにMax-AgeではなくExpires（180日）と同じになっています。

コンテンツ搭載

ほとんどのWebサイトでは、多くのメディアやCSS、JavaScriptライブラリが、さまざまな外部ソース、CDN、クラウドストレージサービスから読み込まれています。どのソースのコンテンツが信頼できるかを確認することは、Webサイトのセキュリティだけでなく、Webサイトのユーザーのセキュリティにとっても重要です。そうでなければ、信頼できないコンテンツが読み込まれた場合、ウェブサイトはクロスサイトスクリプティング攻撃にさらされる可能性があります。

コンテンツセキュリティポリシー

コンテンツセキュリティポリシー (CSP) は、さまざまなコンテンツの読み込みを許可するオリジンを制限することにより、クロスサイトスクリプティングやデータインジェクション攻撃を緩和するために使用される主要な方法です。ウェブサイトには、さまざまな種類のコンテンツのソースを指定するために使用できる数多くのディレクティブがあります。たとえば、script-src はスクリプトを読み込むことができるオリジンやドメインを指定するために使用されます。また、インラインスクリプトと eval() 関数が許可されているかどうかを定義するための値も持っています。

モバイル向けホームページでは、昨年の7.2%から9.3%がCSPを使用しており、ますます多くのウェブサイトがCSPを使用し始めていることがわかります。upgrade-insecure-requestsは、引き続きもっとも頻繁に使用されているCSPです。このポリシーの採用率が高いのは、昨年と同じ理由によるものと思われます。これは簡単でリスクの少ないポリシーで、すべてのHTTPリクエストをHTTPSへアップグレードするのに役立ち、またページで使用されている混合コンテンツをブロックするのにも役に立ちます。frame-ancestorsは、ページを埋め込むことができる有効な親を定義するのを助ける、僅差で2番目のものです。

コンテンツの読み込み元を定義するポリシーの採用は、依然として低い水準にとどまっています。これらのポリシーのほとんどは、破損を引き起こす可能性があるため、実装がより困難になっています。外部コンテンツを許可するためのnonce、ハッシュ、ドメインなどを定義するために、実装に労力を要するのです。

厳格なCSPは攻撃に対する強力な防御となりますが、ポリシーの定義が正しくない場合、望ましくない効果をもたらし有効なコンテンツが、ロードされなくなることがあります。異なるライブラリやAPIがさらにコンテンツを読み込むと、これはさらに難しくなります。

Lighthouse は最近、CSPにそのようなディレクティブがない場合に重大度警告のフラグを立て、XSS攻撃を防ぐためにより厳しいCSPを採用するよう奨励するようになりました。CSPがXSS攻撃の阻止にどのように役立つかは、この章の攻撃の阻止のセクションで詳しく説明します。

ウェブ開発者がCSPポリシーの正しさを評価できるように、非強化の代替案もあります。これは、Content-Security-Policy-Report-Only応答ヘッダーでポリシーを定義することによって有効になります。このヘッダーの普及率はまだかなり低く、モバイルでは0.9%です。しかし、ほとんどの場合、このヘッダーはテスト段階で追加され、後に強制CSPへ置き換えられるので使用率の低さは予想外ではありません。

サイトは report-uri ディレクティブを使用して、CSPエラーを解析できる特定のリンクにCSP違反を報告することもできます。これらは、CSPディレクティブが追加された後に、有効なコンテンツが新しいディレクティブによって偶然にブロックされていないかどうかをチェックするのに役に立ちます。この強力なフィードバック・メカニズムの欠点は、ブラウザの拡張機能や、ウェブサイト所有者がコントロールできないその他の技術によって、CSP報告がノイズになる可能性があることです。

CSPヘッダーの長さの中央値は75バイトと、かなり短い状態が続いています。ほとんどのWebサイトでは、長い厳密なCSPの代わりに、特定の目的のために単一のディレクティブがまだ使用されています。たとえば、24.2%のウェブサイトは upgrade-insecure-requests ディレクティブのみを持っています。

43,488

図12.15. 観測された最長のCSPのバイト数。

一方、最長のCSPヘッダーは、昨年の2倍近い長さになっています。43,488バイトです。

オリジン	デスクトップ	モバイル
https://www.google-analytics.com	0.29%	0.22%
https://www.googletagmanager.com	0.26%	0.22%
https://fonts.googleapis.com	0.22%	0.16%
https://fonts.gstatic.com	0.20%	0.15%
https://www.google.com	0.19%	0.14%
https://www.youtube.com	0.19%	0.13%
https://connect.facebook.net	0.16%	0.11%
https://stats.g.doubleclick.net	0.15%	0.11%
https://www.gstatic.com	0.14%	0.11%
https://cdnjs.cloudflare.com	0.12%	0.10%

図12.16. CSP ポリシーでもっとも頻繁に許可されるホスト。

*-src ディレクティブでもっともよく使われるオリジンは、引き続きGoogleが大きく占めています（フォント、広告、分析）。また、今年はCloudflareの人気ライブラリCDNが10位に表示されています。

サブリソースの整合性

多くのWebサイトでは、JavaScriptライブラリやCSSライブラリを外部のCDNから読み込んでいます。これは、CDNが侵害されたり、攻撃者が頻繁に使用されるライブラリを置き換える他の方法を見つけたりした場合、特定のセキュリティ上の意味を持つことがあります。サブリソースの整合性（SRI）は、そのような結果を回避するのに役立ちますが、悪意のない変更でそのリソースがないとウェブサイトが、機能しない可能性がある場合は他のリスクが発生します。可能であれば、サードパーティからロードするのではなく、セルフホスティングすることが、より安全な選択肢となります。

66.2%

図12.17. 携帯電話のSRIにSHA384ハッシュ関数を使用。

ウェブ開発者は、ウェブサイトにJavaScriptやCSSのコードを含めるために使われる <script> と <link> タグに integrity 属性を追加できます。integrity 属性は、リソースの期待される内容のハッシュ値からなる。ブラウザは取得したコンテンツのハッシュと integrity 属性に記述されたハッシュを比較してその妥当性を確認し、一致した場合にのみリソースをレンダリングできます。

<script src="https://code.jquery.com/jquery-3.6.0.min.js"
  integrity="sha256-/xUj+3OJU5yExlq6GSYGSHk7tPXikynS7ogEvDej/m4="
  crossorigin="anonymous"></script>

ハッシュは SHA256、SHA384、SHA512 の3種類のアルゴリズムで計算される。現在、もっとも利用されているのは SHA384 (モバイルでは66.2%) であり、次いで SHA256 (モバイルでは31.1%) となっています。現在、この3つのハッシュアルゴリズムはすべて安全に使用できると考えられています。

82.6%

図12.18. モバイル向け<script>要素に含まれるSRIの割合。

ここ数年、SRIの利用がやや増加しており、デスクトップで17.5%、モバイルでは16.1%の要素にintegrity属性が含まれています。そのうち82.6%は、モバイルの <script> 要素に含まれています。

しかし、<script>要素については、まだ少数派の選択肢です。ウェブサイト上の <script> 要素で integrity 属性を持つものの割合の中央値は、3.3%です。

ホスト	デスクトップ	モバイル
www.gstatic.com	44.3%	44.1%
cdn.shopify.com	23.4%	23.9%
code.jquery.com	7.5%	7.5%
cdnjs.cloudflare.com	7.2%	6.9%
stackpath.bootstrapcdn.com	2.7%	2.7%
maxcdn.bootstrapcdn.com	2.2%	2.3%
cdn.jsdelivr.net	2.1%	2.1%

図12.20. SRIで保護されたスクリプトが含まれるもっとも一般的なホスト。

SRIで保護されたスクリプトが含まれる一般的なホストのうち、そのほとんどがCDNで構成されていることがわかります。異なるライブラリを使用する場合、複数のウェブサイトで使用される非常に一般的なCDNが3つあります。jQuery、cdnjsとBootstrap。これら3つのCDNが、サンプルのHTMLコードにintegrity属性を備えているのは、おそらく偶然ではないでしょう。開発者がサンプルを使ってこれらのライブラリを埋め込むとき、SRIで保護されたスクリプトが読み込まれていることを確認することになります。

パーミッションポリシー

最近のブラウザは、トラッキングや悪意のある目的に使用できる無数のAPIや機能を提供しており、ユーザーのプライバシーに悪影響を与えることが判明しています。パーミッションポリシー は、ウェブサイトが自身のフレームや埋め込んだiframe内のブラウザ機能の使用を許可またはブロックする機能を提供するウェブプラットフォームAPIです。

Permissions-Policyレスポンスヘッダーにより、ウェブサイトはどの機能を使用したいか、また悪用を制限するためにウェブサイト上でどの強力な機能を禁止したいかを決定できます。パーミッションポリシーは、ジオロケーション、ユーザーメディア、ビデオ自動再生、暗号化メディアデコードなどのAPIを制御するために使用できます。これらのAPIのいくつかは、ユーザーからのブラウザの許可を必要としますが、悪意のあるスクリプトはユーザーが許可のポップアップを取得せずにマイクをオンにすることはできません、ウェブサイトが必要としない場合、特定の機能の使用を完全に制限するために許可ポリシーを使用することは依然として良い習慣です。

このAPI仕様は、以前はフィーチャーポリシーとして知られていましたが、名称が変更されただけでなく、他にも多くの更新が行われています。このFeature-Policyレスポンスヘッダーはまだ使用されていますが、モバイル向けウェブサイトの0.6%しか使用していません。Permissions-Policy レスポンスヘッダーには、異なるAPIに対する許可リストが含まれています。たとえば、Permissions-Policy: geolocation=(self "https://example.com") は、自身のオリジンと “https://example.com“オリジン以外のGeolocation APIの利用を許可しないことを意味します。たとえば、Permissions-Policy: geolocation=()のように、空のリストを指定することで、ウェブサイトでのAPIの使用を完全に無効にすることができる。

モバイルサイトでは、すでに1.3%のサイトがPermissions-Policyを使用していることが確認されています。この新しいヘッダーの使用率が予想以上に高い理由として、一部のウェブサイトの管理者が、ユーザーのプライバシーを保護するためにコホートのフェデレート学習または FLoC（Chromeで実験的に実装）のオプトアウトを選択している可能性が挙げられます。プライバシーの章に詳しい分析が載っています。

ディレクティブ	デスクトップ	モバイル
`encrypted-media`	46.8%	45.0%
`conversion-measurement`	39.5%	36.1%
`autoplay`	30.5%	30.1%
`picture-in-picture`	17.8%	17.2%
`accelerometer`	16.4%	16.0%
`gyroscope`	16.4%	16.0%
`clipboard-write`	11.2%	10.9%
`microphone`	4.3%	4.5%
`camera`	4.2%	4.4%
`geolocation`	4.0%	4.3%

図12.21. フレームにおける allow 指令の普及率。

また、<iframe> 要素の allow 属性を使用すると、埋め込みフレームで使用することを許可されている機能を有効または無効にできます。モバイルの1080万フレームの28.4%が、許可や機能のポリシーを有効にするためallow属性を含んでいます。

例年通り、iframeのallow 属性でもっとも使用されているディレクティブは、埋め込みビデオやメディアのコントロールに関連するものです。もっともよく使われるディレクティブは、引き続き encrypted-media で、これは暗号化メディア拡張APIへのアクセスを制御するために使用されます。

Iframeサンドボックス

iframe内に信頼できない第三者が存在すると、そのページに対してさまざまな攻撃を仕掛けることができます。たとえば、トップページをフィッシングページに誘導したり、偽のアンチウイルス広告を表示するポップアップを起動したり、その他のクロスフレームスクリプティング攻撃を行うことができます。

iframeのsandbox属性は、コンテンツに制限をかけるため、埋め込まれたWebページから攻撃を仕掛ける機会を減らすことができます。属性の値は、すべての制限を適用する場合は空、特定の制限を解除する場合はスペースで区切られたトークンのいずれかになります（いくつかの制限を挙げると埋め込みページはJavaScriptコードを実行できず、フォームは送信できず、ポップアップを作成できません）。広告やビデオなどのサードパーティーコンテンツをiframeで埋め込むことは、ウェブ上では一般的な行為であり、その多くがsandbox属性によって制限されていることは驚くことでありません。デスクトップ用ページのiframeの32.6%が sandbox 属性を持っており、モバイル用ページでは32.6%となっています。

もっともよく使われるディレクティブは allow-scripts で、デスクトップページのすべてのサンドボックスポリシーの99.98%に存在し、埋め込みページがJavaScriptコードを実行することを許可しています。もう1つのディレクティブは事実上すべてのサンドボックスポリシーに存在する allow-same-origin で、埋め込みページがそのオリジンを保持し、たとえば、そのオリジンに設定されたクッキーへアクセスすることを許可します。

攻撃を阻止する

ウェブアプリケーションは、複数の攻撃に対して脆弱である可能性があります。幸いある種の脆弱性を防ぐメカニズムがいくつか存在します（たとえば、クリックジャッキング攻撃に対抗するにはX-Frame-Optionsや、CSPのframe-ancestorsディレクティブによるフレーム保護が必要です）、あるいは攻撃の結果を制限することが可能です。これらの保護機能のほとんどはオプトイン方式であるため、ウェブ開発者が適切なレスポンスヘッダーを設定することで有効化する必要があります。大規模な場合、ヘッダーの存在は、ウェブサイトのセキュリティ衛生状態や、開発者がユーザーを保護するインセンティブについて、何かを教えてくれるかもしれません。

セキュリティ機能の採用

図12.23. モバイルページにおけるサイトリクエストのセキュリティヘッダーの採用。

本章でもっとも有望かつ明るい発見は、おそらく、セキュリティ機構の一般的な採用が増え続けていることです。これは、攻撃者が特定のウェブサイトを悪用するのがより困難になることを意味するだけでなく、より多くの開発者が、自分たちが構築するウェブ製品のセキュリティを重視していることを示すものです。全体として、昨年と比較して、セキュリティ機能の採用が10～30%相対的に増加していることがわかります。セキュリティ関連の仕組みでもっとも導入が進んでいるのは、the Reporting API の Report-To ヘッダーで、導入率は2.6%から12.2%と、ほぼ4倍に増加しています。

このように、セキュリティ機構の採用率が上昇し続けていることは注目に値しますが、まだまだ改善の余地は残されています。もっとも広く利用されているセキュリティメカニズムは、依然として X-Content-Type-Options ヘッダーであり、モバイルでクロールしたウェブサイトの36.6% でMIMEスニッフィング攻撃から保護するために利用されています。このヘッダーに続くのは、X-Frame-Optionsヘッダーで、全サイトの29.4%で有効になっています。興味深いことに、CSPのより柔軟なframe-ancestorsディレクティブを使用しているウェブサイトは、わずか5.6%に過ぎません。

もう1つの興味深いのは、X-XSS-Protectionヘッダーの進化です。この機能は、レガシーブラウザのXSSフィルターを制御するために使用されます。EdgeとChromeは意図しない新たな脆弱性をもたらす恐れがあるとして、XSSフィルターをそれぞれ2018年7月、2019年8月に引退させたそうです。しかし、X-XSS-Protectionヘッダーは昨年より8.5%も多いことがわかりました。

`<meta>` 要素で有効な機能

レスポンスヘッダーを送信することに加えて、いくつかのセキュリティ機能は <meta> 要素に name 属性を http-equiv に設定するとHTMLレスポンスボディで有効にできます。セキュリティ上の理由から、この方法で有効にできるポリシーは限られています。より正確には、コンテンツセキュリティポリシーとリファラーポリシーのみが <meta> タグで設定できます。それぞれ、0.4%と2.6%のモバイルサイトがこの方法でメカニズムを有効にしていることがわかりました。

3,410

図12.24. X-Frame-Optionsを<meta>タグに記述しているが、実際にはブラウザに無視されているサイトの数。

他のセキュリティ機構が<meta>タグで設定されている場合、ブラウザはこれを実際に無視します。興味深いことに、3,410のサイトが <meta> タグを使って X-Frame-Options を有効にしようとしており、その結果、クリックジャック攻撃から守られているという誤った認識を抱いていたことがわかりました。同様に、数百のウェブサイトが、セキュリティ機能をレスポンスヘッダーの代わりに<meta>タグへ記述することで導入に失敗しました（X-Content-Type-Options: 357, X-XSS-Protection: 331, Strict-Transport-Security: 183）。

CSPによるXSS攻撃の阻止

CSPは、クリックジャック攻撃、混合コンテンツの取り込みの防止、コンテンツを取り込む信頼できるソースの決定（上で述べたとおり）など、多数のものから守るために使用できます。

さらに、XSS攻撃から身を守るために必要不可欠な仕組みです。たとえば、制限的な script-src ディレクティブを設定することで、ウェブ開発者はアプリケーションのJavaScriptコードだけが実行されるようにできます（攻撃者のコードは実行されません）。さらに、DOMベースのクロスサイトスクリプティングを防御するために、信頼できるタイプ を使うことができます。これは、CSPのrequire-trusted-types-for ディレクティブを使って有効にすることが可能です。

キーワード	デスクトップ	モバイル
`strict-dynamic`	5.2%	4.5%
`nonce-`	12.1%	17.6%
`unsafe-inline`	96.2%	96.5%
`unsafe-eval`	82.9%	77.2%

図12.25. default-src または script-src ディレクティブを定義するポリシーに基づく CSP キーワードの普及率です。

CSPの採用は全体的に緩やかな増加（17％）ですが、それ以上に興味深いのは、strict-dynamicとnoncesの利用が同じ傾向を維持しているか、わずかに増加していることです。たとえば、デスクトップサイトでは、strict-dynamicの使用率が2.4%昨年から、今年は5.2%に増加しました。同様に、noncesの使用率も8.7%から12.1%に増加しています。

一方、問題の多いディレクティブである unsafe-inline と unsafe-eval の使用率は、まだかなり高いことがわかります。しかし、これらが strict-dynamic と共に使用されている場合、モダンブラウザはこれらの値を無視し、 strict-dynamic をサポートしていない古いブラウザは引き続きウェブサイトを使用することができることに留意すべきです。

XS-Leaksに対する防御

Web開発者がSpectreのような攻撃などのマイクロアーキテクチャ攻撃や、一般に XS-Leaks と呼ばれる攻撃からWebサイトを防御できるように、さまざまな新しいセキュリティ機能を導入しています。これらの攻撃の多くがここ数年で発見されたものであることを考えると、それらに対処するためのメカニズムも明らかにごく最近のものであり、これが比較的低い普及率の理由かもしれません。とはいえ、昨年と比較すると、クロスオリジンポリシーの採用が大幅に増えています。

リソースをどのように含めるか（クロスオリジン、同一サイト、同一オリジン）をブラウザへ示すために使用されるCross-Origin-Resource-Policy は、昨年1,712サイトから106,443サイト (1.5%)で存在することがわかりました。この理由としてもっとも考えられるのは、クロスオリジンの分離が SharedArrayBuffer やハイレゾタイマーなどの機能を使うために必要で、それにはサイトの Cross-Origin-Embedder-Policyをrequire-corpに設定する必要があるからだと思われます。要するに、これらの機能を使いたいサイトのために、ロードされたすべてのサブリソースに Cross-Origin-Resource-Policy レスポンスヘッダーを設定することを要求しているのです。

その結果、several CDN は現在、ヘッダーの値を cross-origin に設定します（CDNのリソースは通常クロスサイトのコンテキストに含まれるべきものだからです）。CORPヘッダーの値をcross-originに設定しているサイトは96.8%であるのに対し、same-siteに設定しているサイトは2.9%、より限定的なsame-originを使用しているサイトは0.3%であり、これは実際にそうであるということがわかります。

この変化に伴い、Cross-Origin-Embedder-Policyの採用が着実に増えているのは当然のことです。2021年には、911サイトがこのヘッダーを有効にし、昨年の6サイトを大幅に上回りました。来年、これがさらにどのように発展していくのか、興味深いところです。

最後に、もう1つのXS-Leak対策ヘッダーであるCross-Origin-Opener-Policyも昨年と比較して大幅に増加しています。現在、このセキュリティ機構を有効にしているサイトは15,727件で、特定のXS-Leak攻撃から保護されているサイトが31件しかなかった昨年と比較すると、大幅に増加していることがわかりました。

ウェブ暗号化API

Web開発において、セキュリティは中心的な課題の1つとなっています。ウェブ暗号化API W3C勧告は2017年に導入され、クライアントサイドでサードパーティのライブラリなしで基本的な暗号操作（ハッシュ、署名生成・検証、暗号化・復号化など）を実行できるようになりました。このJavaScript APIの利用状況を分析しました。

暗号化API	デスクトップ	モバイル
`CryptoGetRandomValues`	70.4%	67.4%
`SubtleCryptoDigest`	0.4%	0.5%
`SubtleCryptoEncrypt`	0.4%	0.3%
`CryptoAlgorithmSha256`	0.3%	0.3%
`SubtleCryptoGenerateKey`	0.3%	0.2%
`CryptoAlgorithmAesGcm`	0.2%	0.2%
`SubtleCryptoImportKey`	0.2%	0.2%
`CryptoAlgorithmAesCtr`	0.1%	< 0.1%
`CryptoAlgorithmSha1`	0.1%	0.1%
`CryptoAlgorithmSha384`	0.1%	0.2%

図12.26. よく使われる暗号API

機能の人気は前年とほぼ同じで71.8％から72.5％へと0.7％の微増にとどまっています。今年も Cypto.getRandomValues がもっとも人気のある暗号化APIです。開発者は強力な擬似乱数を生成することができる。Google Analyticsのスクリプトがこの機能を利用しているため、やはりGoogle Analyticsの影響が大きいと思われます。

なお、受動的なクローリングを行っているため、機能実行前に何らかのインタラクションが必要なケースを特定できず、本節の結果は限定的なものとなっています。

ボット対策サービスの活用

多くのサイバー攻撃は自動化されたボット攻撃に基づいており、それに対する関心も高まっているようです。Imperva社の2021年の悪意のあるBotレポートによると、今年に入ってから悪質ボットの数が25.6%増加したとのことです。なお、2019年から2020年の増加率は、前回のレポートによると24.1%となっています。以下の表では、悪意あるボットからの防御のために、ウェブサイトがどのような対策をとっているかについての結果を示しています。

サービスプロバイダー	デスクトップ	モバイル
reCAPTCHA	10.2%	9.4%
Imperva	0.3%	0.3%
Sift	0.1%	0.1%
Signifyd	0.03%	0.03%
hCaptcha	0.03%	0.02%
Forter	0.03%	0.03%
TruValidate	0.03%	0.02%
Akamai Web Application Protector	0.02%	0.02%
Kount	0.02%	0.02%
Konduto	0.02%	0.02%
PerimeterX	0.02%	0.01%
Tencent Waterproof Wall	0.01%	0.01%
Others	0.03%	0.04%

図12.27. ボット対策サービスのプロバイダー別利用状況。

当社の分析によると、悪意のあるボットと戦うためのメカニズムを使用しているのは、デスクトップWebサイトの10.7％未満、モバイルWebサイトの9.9％未満であることがわかりました。昨年は8.3%、7.3%でしたので、前年比で約30%増加しています。今年も、モバイル版よりもデスクトップ版の方がボット対策の仕組みが多く確認されています（10.8％対9.9％）。

また、我々のデータセットでは、ボット保護プロバイダーとして新たに人気のあるプレーヤーが見られます（例：hCaptcha）。

セキュリティメカニズム採用のドライバー

Webサイトがセキュリティ対策に投資する背景には、さまざまな影響が考えられます。そのような要因の例としては社会的なもの（例：特定の国でよりセキュリティ志向の教育が行われている、またはデータ侵害の場合により懲罰的な措置を取る法律）、技術的なもの（例：特定の技術スタックでセキュリティ機能を採用することが容易または特定のベンダーがデフォルトでセキュリティ機能を有効にする）、または脅威ベースのもの（例：広く普及しているウェブサイトは、知名度が低いウェブサイトより標的型攻撃に直面するかもしれない）などがあります。このセクションでは、これらの要因がセキュリティ機能の採用にどの程度影響するかを評価しようとします。

ウェブサイトの訪問者はどこから来るか

デフォルトでHTTPSを採用するのが全般的に進んでいることがわかりますが、訪問者の出身国によって、サイト間の採用率にばらつきがあります。

昨年と比較して、オランダがトップ5に入ったことがわかり、オランダ人はトランスポート層攻撃に対して比較的保護されていることがわかります。オランダの人々が頻繁に訪れるサイトの95.1％がHTTPSを有効にしています（昨年は93.0％）。実際、オランダだけでなく、ほぼすべての国でHTTPSの導入が進んでいることがわかります。

また、昨年は最悪の結果だったいくつかの国が大きく躍進したことは、非常に心強いことです。たとえば、イラン（HTTPSの普及率がもっとも高かった国）の人々が訪問したサイトは、昨年と比較して13.4%も多くHTTPSに対応しています（74.3%から84.3%）。もっとも導入が進んでいる国ともっとも進んでいない国の差は小さくなってきていますが、まだ大きな努力が必要です。

CSPや X-Frame-Options などの特定のセキュリティ機能の採用状況を見ると、国によってさらに顕著な違いがあり、成績上位の国のサイトは成績下位の国に比べて、これらのセキュリティ機能を採用する傾向が2～4倍も高いことが分かっています。また、HTTPSの採用率が高い国は、他のセキュリティメカニズムの採用率も高い傾向にあることがわかります。これは、セキュリティはしばしば全体的に考えられ、さまざまな角度からカバーする必要があることを示しています。攻撃者は、悪用可能な脆弱性を1つ見つけるだけでよいのに対して、開発者は、あらゆる側面が確実に保護されていることを確認する必要があります。

Technology stack

技術紹介	デフォルトで有効なセキュリティ機能
オートマティック (PaaS)	Strict-Transport-Security (97.8%)
ブロガー（ブログ）	X-Content-Type-Options (99.6%), X-XSS-Protection (99.6%)
Cloudflare (CDN)	Expect-CT (93.1%), Report-To (84.1%)
Drupal (CMS)	X-Content-Type-Options (77.9%), X-Frame-Options (83.1%)
Magento (E-commerce)	X-Frame-Options (85.4%)
Shopify (E-commerce)	Content-Security-Policy (96.4%), Expect-CT (95.5%), Report-To (95.5%), Strict-Transport-Security (98.2%), X-Content-Type-Options (98.3%), X-Frame-Options (95.2%), X-XSS-Protection (98.2%)
Squarespace (CMS)	Strict-Transport-Security (87.9%), X-Content-Type-Options (98.7%)
Sucuri (CDN)	Content-Security-Policy (84.0%), X-Content-Type-Options (88.8%), X-Frame-Options (88.8%), X-XSS-Protection (88.7%)
Wix (Blogs)	Strict-Transport-Security (98.8%), X-Content-Type-Options (99.4%)

図12.30. さまざまな技術によるセキュリティ機能の採用。

特定のセキュリティメカニズムの採用に強く影響するもう1つの要因は、ウェブサイトを構築するために使用されている技術スタックです。場合によってはセキュリティ機能がデフォルトで有効になっていたり、ブログシステムによっては、レスポンスヘッダーに対する制御がウェブサイト所有者の手を離れ、プラットフォーム全体のセキュリティ設定が行われていたりすることがあります。

また、CDNは、とくにトランスポートのセキュリティに関わる場合、追加のセキュリティ機能を追加することがあります。上の表では、少なくとも25,000のサイトで使用され、特定のセキュリティメカニズムの採用率が著しく高い9つのテクノロジーをリストアップしました。たとえば、Shopifyのeコマースシステムで構築されたサイトでは、7つのセキュリティ関連ヘッダー（Content-Security-Policy, Expect-CT, Report-To, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options とX-XSS-Protection）の適用率が非常に高く（95%以上）なっていることが見て取れるでしょう。

図12.31. Shopifyサイトでの採用率が95％を超えるセキュリティ機能の数々。

これらの技術を使用するコンテンツにばらつきがあるにもかかわらず、これらのセキュリティ機構を統一的に採用することが可能であることは、素晴らしいことだと思います。

83.1%

図12.32. DrupalサイトがデフォルトのXFOヘッダーを保持している割合です。

このリストのもう1つの興味深い項目はDrupalで、そのウェブサイトではX-Frame-Optionsヘッダーの採用率が83.1%でした（昨年の81.8%と比較して若干改善されています）。このヘッダーはデフォルトで有効なので、Drupalサイトの大多数がこれを使用し、クリックジャック攻撃から守っていることは明らかです。近い将来、古いブラウザとの互換性のために X-Frame-Options ヘッダーを残すことは理にかなっていますが、サイトオーナーは同じ機能を持つ推奨の Content-Security-Policy ヘッダーディレクティブ frame ancestors への移行を検討すべきことに留意してください。

セキュリティ機能の採用の文脈で探るべき重要な点は、多様性です。たとえば、Cloudflareは最大のCDNプロバイダーであり、何百万ものウェブサイトを支えています（これに関するさらなる分析については、CDNの章を参照してください）。Cloudflareがデフォルトで有効にする機能は、全体として大きな採用率になります。実際、Expect-CT機能を採用しているサイトの98.2%はCloudflareによって提供されており、このメカニズムの採用がかなり限定的な分布であることを示しています。

しかし、全体的に見ると、DrupalやCloudflareのような単一のアクターがセキュリティ機能の採用を技術的に牽引するという現象は異常値であり、時間の経過とともに少なくなっているように見受けられます。これは、ますます多様化するウェブサイトがセキュリティ機構を採用し、より多くのウェブ開発者がその利点を認識するようになっていることを意味します。たとえば、昨年はコンテンツセキュリティポリシーを設定したサイトの44.3%がShopifyによるものでしたが、今年はCSPを有効にしたサイト全体の32.9%がShopifyによるものにとどまっています。一般的に普及率が高まっていることと合わせると、これは素晴らしいニュースです。

ウェブサイトの人気度

多くの人が訪れるWebサイトでは、潜在的な機密情報を持つユーザーが多く、攻撃者が集まりやすいため、標的型攻撃に遭いやすいと考えられます。したがって、多くの人が訪れるウェブサイトは、ユーザーを保護するために、より多くのセキュリティ投資を行うことが予想されます。この仮説が成り立つかどうかを評価するために、実際のユーザーデータを使って、どのウェブサイトがもっとも訪問されているかを調べるChromeユーザー体験レポートが提供するランキング（上位1000、1万、10万、100万とデータセット内の全サイトでランキング）を使用しました。

図12.33. ファーストパーティコンテキストに設定されたセキュリティヘッダーのランク別普及率。

X-Frame-Options (XFO)、Content Security Policy (CSP)、Strict Transport Security (HSTS) という特定のセキュリティ機能の採用が、サイトのランキングに大きく関係していることがわかります。たとえば、アクセス数の多い1,000のサイトでは、全体の採用率と比較して、あるセキュリティヘッダーを採用する割合が約2倍になっています。また、各機能の採用率は、ランキング上位のサイトほど高いことがわかります。

一方では、より多くの訪問者を集めるサイトでより優れた「セキュリティ衛生」を実現すれば、より多くのユーザー（よく知られた信頼できるサイトと個人データを共有する傾向がある）の利益につながるということです。一方、訪問者の少ないサイトでのセキュリティ機能の採用率が低いのは、これらの機能を（正しく）実装するためには、まだかなりの投資が必要であることを示しているのかもしれません。小規模なWebサイトでは、この投資が必ずしも有効であるとは限りません。願わくは、特定のテクノロジースタックで、デフォルトで有効になっているセキュリティ機能がさらに増え、ウェブ開発者がそれほど努力しなくても多くのサイトのセキュリティがさらに強化されることを期待します。

ウェブ上での不正行為

暗号通貨は、現代の社会でますます身近な存在になっています。世界的な暗号通貨の普及は、パンデミック発生当初から急増しています。その経済的な効率性から、サイバー犯罪者も暗号通貨に関心を持つようになりました。そのため、新たな攻撃ベクトルが生まれたのです。クリプトジャッキングです。攻撃者は、WebAssemblyの力を発見し、ウェブサイト訪問者がウェブサイト上でサーフィンしている間に暗号通貨をマイニングするために悪用されています。

そこで、Web上でのクリプトマイナーの利用状況について、次の図に示すような調査結果を得た。

私たちのデータセットによると、最近まで、クリプトマイナーを使用したウェブサイトの数は非常に安定して減少していました。しかし、現在では、そのようなウェブサイトの数が過去2カ月間で10倍以上に増加していることが確認されています。このようなピックは、たとえば、広範なクリプトジャック攻撃が行われたときや、人気のあるJSライブラリが感染したときなど非常に典型的なものです。

次に、クリプトマイナーの市場シェアについて、次の図に示す。

Coinhiveは、CoinImpに抜かれ、クリプトマイニングサービスの主流となったことがわかります。その大きな理由のひとつが、2019年3月にCoinhiveが閉鎖されたことです。興味深いことに、このドメインは現在Troy Huntによって所有されており、Coinhiveスクリプトをまだホストしているサイト（デスクトップ: 5.7%, モバイル: 9.0%）に、しばしば彼らの知らないところでホストしていることを意識させようとウェブサイトに積極的にバナーを表示させているのだそうです。これは、Coinhiveのスクリプトが運営停止から2年以上経過しても普及していることと、サードパーティーのリソースが運営停止になった場合、引き継がれる可能性があることを反映しています。Coinhiveの消滅により、CoinImpは明らかに市場リーダー（シェア84.9%）となった。

この結果は、クリプトジャッキングが依然として深刻な攻撃ベクトルであることを示唆しており、必要な対策を講じる必要があることを示しています。

なお、これらのWebサイトのすべてが感染しているわけではありません。ウェブサイト運営者は、ウェブサイトの資金調達のために、（広告を表示する代わりに）この技術を展開することもあります。しかし、この手法の使用については、技術的、法的、倫理的にも大きく議論されています。

また、今回の結果は、クリプトジャッキングに感染したウェブサイトの実態を表していない可能性があることをご了承ください。クローラーの実行は月に1回であるため、クリプトマイナーを実行しているすべてのWebサイトを発見できるわけではありません。たとえば、あるWebサイトがX日間だけ感染したままで、私たちのクローラーが走った日には感染していない場合などがこれにあたります。

`security.txt`

security.txt は、ウェブサイトが脆弱性報告の基準を提供するためのファイル形式です。ウェブサイト提供者は、このファイルに連絡先、PGPキー、ポリシーなどの情報を記載できます。ホワイトハットハッカーは、この情報を利用して、これらのウェブサイトのセキュリティ分析を行ったり、脆弱性を報告したりできます。

その結果、/.well-known/security.txtのURLを要求したところ、5％弱のウェブサイトが応答を返していることがわかりました。しかし、これらの多くは基本的に404ページであり、ステータスコード200を誤って返しているため、使用率はもっと低いと思われます。

Policy は security.txt ファイルでもっとも使用されているプロパティですが、それでも security.txt のURLを持つサイトの6.4%でしか使用されていないことがわかります。このプロパティには、ウェブサイトの脆弱性開示ポリシーへのリンクが含まれており、研究者が従うべき報告慣習を理解するのに役立ちます。ほとんどのファイルが Policy 値を持つことが予想されるため、このプロパティは security.txt の実際の使用状況のより良い指標となるでしょう。つまり、すべてのサイトのうち、上記の5％ではなく、0.3％に近い数の「本物の」security.txt ファイルが、存在する可能性があるということです。

もう1つの興味深い点は、この「本物の」security.txt URLのサブセットだけを見ると、Tumblrが63%～65%の使用率を占めていることです。これらのドメインでは、デフォルトでTumblrの連絡先情報に設定されているようです。これは、単一のプラットフォームがこれらの新しいセキュリティ機能の採用を促進できることを示す一方で、実際のサイト利用がさらに減少していることを示す素晴らしいことです。

その他によく使われるプロパティは Canonical と Encryption です。Canonical は security.txt ファイルがどこにあるのかを示すために使用されます。もし security.txt ファイルを取得するために使用したURIが Canonical フィールドのリストURIと一致しない場合は、ファイルの内容を信頼すべきではありません。Encryptionはセキュリティ研究者へ暗号化された通信に使用するための暗号鍵を提供します。

結論

当社の分析によると、プロバイダー側に関するWebセキュリティの状況は、以前と比較して改善されていることがわかります。たとえば、HTTPSの利用は、過去12か月で10％近く増加していることがわかります。また、クッキーの保護やセキュリティヘッダーの使用も増えていることがわかります。

これらの増加は、私たちがより安全なウェブ環境に移行していることを示していますが、今日の私たちのウェブが十分に安全であることを意味するものではありません。まだまだ改善しなければならないことがあります。たとえば、私たちは、ウェブコミュニティがセキュリティヘッダーをもっと重視すべきであると考えています。これらは、ウェブ環境やユーザーを攻撃から守るために非常に有効な拡張機能です。

また、悪意のあるボットからプラットフォームを保護するために、ボット保護機構をより多く採用できます。さらに昨年の私たちの分析や、HTTP Archiveデータセットを用いたupdate behavior of websites に関する別の研究では、ウェブサイトのコンポーネントが熱心にメンテナンスされておらず、ウェブ環境の攻撃表面を増大させていることが示されました。

また、攻撃者は、私たちが採用しているセキュリティの仕組みを回避するために、新しい技術の開発に熱心に取り組んでいることも忘れてはならない。

この分析によって、私たちのウェブのセキュリティの概要を結晶化することを試みました。私たちの調査は広範囲におよびますが、私たちの方法論では、現代のウェブセキュリティのすべての側面のサブセットを見ることができるだけです。たとえば、クロスサイトリクエストフォージェリ（CSRF）やクロスサイトスクリプティング（XSS）のような攻撃を軽減・防止するためにサイトが採用している追加措置についてはわかりません。このように、この章で描かれた絵は不完全なものですが、今日のWebセキュリティの状況を示す確かな方向性を示しています。

この分析から得られることは、私たちウェブコミュニティはより良くより安全な明日のために、ウェブ環境をより安全にするため、より多くの関心と資源を投資し続けなければならないということです。