サブリソース完全性

1. 序論

Web 上のサイトやアプリケーションが、単一のオリジンからのリソースだけで構成されることはまれである。たとえば、作者はスクリプトやスタイルをさまざまなサービスやコンテンツ配信ネットワークから取得し、配信された表現が実際に読み込むことを期待したものであると信頼しなければならない。攻撃者が DNS [RFC1035] ポイズニング、またはその他のそのような手段によって、敵対的なサーバーからコンテンツをダウンロードするようにユーザーをだませる場合、作者に対抗手段はない。同様に、Content Delivery Network (CDN) サーバー上のファイルを置き換えられる攻撃者は、任意のコンテンツを注入する能力を持つ。

安全なチャネル上でリソースを配信することで、このリスクの一部は軽減される： TLS [TLS]、HSTS [RFC6797]、およびピン留めされた公開鍵 [RFC7469] により、ユーザーエージェントは自分が通信していると考えるサーバーと実際に通信していることをかなり確信できる。しかし、これらの仕組みが認証するのはサーバーだけであり、コンテンツではない。サーバーにアクセスできる攻撃者（または管理者）は、罰せられることなくコンテンツを操作できる。理想的には、作者はサーバーの鍵だけでなくコンテンツもピン留めでき、リソースの正確な表現、およびその表現だけが読み込まれて実行されることを保証できるべきである。

この文書はそのような検証方式を規定し、作者が読み込むことを期待するリソースの表現の暗号学的ハッシュを含む integrity 属性で 2 つの HTML 要素を拡張する。たとえば、作者はあるフレームワークを自身のオリジンでホストするのではなく、共有サーバーから読み込みたい場合がある。 https://example.com/example-framework.js の期待される SHA-384 ハッシュが Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7 であると指定することは、ユーザーエージェントがその URL から読み込むデータが、その中に含まれる JavaScript を実行する前に、その期待されるハッシュと一致することを検証できることを意味する。この完全性検証により、攻撃者が悪意あるコンテンツを置き換えられるリスクが大幅に低減される。

この例は、次のようにハッシュを script 要素に追加することでユーザーエージェントに伝えられる：

<script src="https://example.com/example-framework.js"
        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7"
        crossorigin="anonymous"></script>

もちろん、完全性検証の恩恵を受けるレスポンス型はスクリプトだけではない。ここで規定する方式は link にも適用され、この仕様の将来の版ではこの適用範囲が拡大される可能性が高い。

テスト

subresource-integrity.html （ライブテスト）（ソース）

1.1. 目標

サードパーティサービスの侵害が、そのスクリプトを含むすべてのサイトの侵害を自動的に意味してはならない。コンテンツ作者は、読み込むコンテンツに対する期待を指定できる仕組みを持つことになる。つまり、たとえば特定の URL をたまたま持つ任意のスクリプトではなく、特定のスクリプトを読み込めるということである。
検証機構には、不正なレスポンスを受信したことを作者に通知するエラー報告機能があるべきである。

1.2. ユースケース/例

1.2.1. リソース完全性

作者は、世界中に分散したユーザーのためにパフォーマンスを向上させる目的で、コンテンツ配信ネットワークを使用したいと考えている。しかし、CDN のサーバーが作者の期待するコードだけを配信することを保証することが重要である。 CDN の侵害（または予期しない悪意ある振る舞い）によってそのサイトが望ましくない形で変更されるリスクを軽減するため、次の完全性メタデータが、ページに含まれる link 要素に追加される：
```
<link rel="stylesheet" href="https://site53.example.net/style.css"
      integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
      crossorigin="anonymous">
```
作者は、サードパーティの分析サービスによって提供される JavaScript を含めたいと考えている。慎重にレビューされたコードだけが実行されることを保証するため、作者はそのスクリプトの完全性メタデータを生成し、それを script 要素に追加する：
```
<script src="https://analytics-r-us.example.com/v1.0/include.js"
        integrity="sha384-MBO5IDfYaE6c6Aao94oZrIOiC6CGiSN2n4QUbHNPhzk5Xhm0djZLQqTpL0HzTUxk"
        crossorigin="anonymous"></script>
```
ユーザーエージェントは、高権限の HTML コンテキスト（たとえば、ブラウザーの新しいタブページ）で実行される JavaScript コードが、表示前に操作されていないことを保証したいと考えている。完全性メタデータは、改変された JavaScript がこれらのページの高権限コンテキストで実行されるリスクを軽減する。

2. 主要な概念と用語

この節では、文書全体で使用されるいくつかの用語を定義する。

ダイジェストという用語は、任意のデータブロックに対して暗号学的ハッシュ関数を実行した結果を base64 符号化したものを指す。

オリジンおよび同一オリジンという用語は HTML で定義される。[HTML]

base64 符号化は RFC 4648 の第 4 節で定義される。 [RFC4648]

SHA-256、SHA-384、および SHA-512 は、 NIST によって定義される SHA-2 暗号学的ハッシュ関数群の一部である。 [SHA2]

有効な SRI ハッシュアルゴリズムトークン集合は、順序集合 « "sha256", "sha384", "sha512" »（それぞれ SHA-256、 SHA-384、および SHA-512 に対応）である。この集合の順序には意味があり、より強いアルゴリズムほど集合内で後に現れる。追加情報については、 § 3.2.2 優先度および§ 3.3.3 set から最強のメタデータを取得するを参照。

文字列は、その ASCII 小文字化が有効な SRI ハッシュアルゴリズムトークン集合に含まれる場合、有効な SRI ハッシュアルゴリズムトークンである。

2.1. 文法上の概念

この文書で使用される Augmented Backus-Naur Form (ABNF) 記法は、 RFC5234 で規定される。[ABNF]

付録 B.1 of [ABNF] は、VCHAR（表示文字）および WSP （空白）規則を定義する。

Content Security Policy は、base64-value および hash-algorithm 規則を定義する。[CSP]

3. フレームワーク

ここで規定される完全性検証機構は、要するに、リソースに対して十分に強い暗号学的ダイジェストを生成し、そのダイジェストをユーザーエージェントに送信して、レスポンスの検証に使用できるようにするプロセスである。

3.1. 完全性メタデータ

レスポンスの完全性を検証するため、ユーザーエージェントはリクエストの一部として完全性メタデータを必要とする。このメタデータは、次の情報片から構成される：

暗号学的ハッシュ関数（"alg"）
ダイジェスト（"val"）
オプション（"opt"）

レスポンスの完全性を検証するには、ハッシュ関数とダイジェストが提供されなければならない。

注: 現時点では、オプションは定義されていない。しかし、この仕様の将来の版では、MIME タイプ [MIME-TYPES] などのオプションが定義される可能性がある。

このメタデータは、Content Security Policy Level 2 仕様の第 4.2 節における hash-source（単一引用符なし）と同じ形式で符号化されなければならない。

たとえば、alert('Hello, world.'); という文字列だけを含むスクリプトリソースが与えられた場合、作者はハッシュ関数として SHA-384 を選択するかもしれない。 H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO は、その結果となる base64 符号化されたダイジェストである。これは次のように符号化できる：

sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO

ダイジェストは、任意の数のユーティリティを使って生成できる。たとえば OpenSSL は、かなり一般的に利用可能である。この節の例は、次のコマンドラインの結果である：

echo -n "alert('Hello, world.');" | openssl dgst -sha384 -binary | openssl base64 -A

3.2. 暗号学的ハッシュ関数

適合するユーザーエージェントは、リクエストの完全性メタデータの一部として使用するために、 SHA-256、SHA-384、および SHA-512 暗号学的ハッシュ関数をサポートしなければならず、この文書の将来の反復で定義される追加のハッシュ関数をサポートしてもよい。

注: この文書でサポートされるアルゴリズムは、（現時点では！）第二原像攻撃および衝突攻撃に耐性があると考えられている。サポート対象アルゴリズム集合への将来の追加/削除では、同様の標準を適用することが強く推奨される。§ 5.2 ハッシュ衝突攻撃を参照。

3.2.1. 俊敏性

将来の暗号学的発見に対応する俊敏性を提供するため、単一のリソースに複数の完全性メタデータ集合を関連付けてもよい。たとえば、前節で説明したリソースは、次のいずれかのハッシュ式によって記述されてもよい：

sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw==

作者は、たとえば両方を指定することを選択できる：

<script src="hello_world.js"
   integrity="sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO
              sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw=="
   crossorigin="anonymous"></script>

この場合、ユーザーエージェントはリスト内で最も強いハッシュ関数を選択し、そのメタデータを使用してレスポンスを検証する（下記の § 3.3.2 メタデータを構文解析するおよび§ 3.3.3 set から最強のメタデータを取得するアルゴリズムで説明する）。

ハッシュ関数が安全でないと判断された場合、ユーザーエージェントは、その安全でないハッシュ関数を用いた完全性検証のサポートを非推奨にし、最終的に削除すべきである。ユーザーエージェントは、非推奨の関数に基づくダイジェストを使用してレスポンスの妥当性を確認してもよい。

作者が古いユーザーエージェントに足を引っ張られずに、より強いハッシュ関数へ切り替えられるようにするため、サポートされていないハッシュ関数を用いた検証は、完全性値が提供されなかったかのように振る舞う（下記の § 3.3.4 bytes は metadataList と一致するか？アルゴリズムを参照）。作者は強いハッシュ関数を使用し、より強いハッシュ関数が利用可能になり次第、それらへの移行を開始することが奨励される。

3.2.2. 優先度

ハッシュアルゴリズムの優先順位は、有効な SRI ハッシュアルゴリズムトークン集合におけるそれぞれのトークンの順序によって規定される。その集合でより前に現れるアルゴリズムは、その集合でより後に現れるアルゴリズムより弱い。

現在規定されているとおり、SHA-256 は SHA-384 より弱く、さらに SHA-512 より弱い。この仕様では現在、他のハッシュアルゴリズムはサポートされていない。

3.3. レスポンス検証アルゴリズム

3.3.1. `algorithm` を `bytes` に適用する

result を、algorithm を bytes に適用した結果とする。
result を base64 符号化した結果を返す。

3.3.2. メタデータを構文解析する

文字列 metadata が与えられてメタデータを構文解析するよう求められたときは、次の手順を実行する：

注: このアルゴリズムは、ユーザーエージェントが理解するハッシュ関数を持つハッシュ式の集合を返す。

result を空集合とする。
metadata を空白で分割することによって返される各 item について：
1. expression-and-options を、 item を U+003F (?) で分割する結果とする。
2. algorithm-expression を expression-and-options[0] とする。
3. base64-value を空文字列とする。
4. algorithm-and-value を、 algorithm-expression を U+002D (-) で分割する結果とする。
5. algorithm を algorithm-and-value[0] とする。
6. algorithm が有効な SRI ハッシュアルゴリズムトークンでない場合、継続する。
7. algorithm-and-value[1] が存在する場合、 base64-value を algorithm-and-value[1] に設定する。
8. metadata を、順序付きマップ «["alg" → algorithm, "val" → base64-value]» とする。
  
  注: options は定義されていないため（§ 3.1 完全性メタデータを参照）、対応するエントリは metadata に設定されない。将来の版で options が定義された場合、 expression-and-options[1] を options として利用できる。
9. metadata を result に付加する。
result を返す。

3.3.3. `set` から最強のメタデータを取得する

result を空集合とし、strongest を null とする。
set 内の各 item について：
1. 表明：item["alg"] は有効な SRI ハッシュアルゴリズムトークンである。
2. result が空集合である場合：
  1. item を result に付加する。
  2. strongest を item に設定する。
  3. 継続する。
3. currentAlgorithm を strongest["alg"] とし、 currentAlgorithmIndex を有効な SRI ハッシュアルゴリズムトークン集合内の currentAlgorithm のインデックスとする。
4. newAlgorithm を item["alg"] とし、 newAlgorithmIndex を有効な SRI ハッシュアルゴリズムトークン集合内の newAlgorithm のインデックスとする。
5. newAlgorithmIndex が currentAlgorithmIndex より小さい場合、継続する。
6. そうでなく、newAlgorithmIndex が currentAlgorithmIndex より大きい場合：
  1. strongest を item に設定する。
  2. result を « item » に設定する。
7. そうでなければ、newAlgorithmIndex と currentAlgorithmIndex は同じ値である。item を result に付加する。
result を返す。

3.3.4. `bytes` は `metadataList` と一致するか？

parsedMetadata を、 metadataList を構文解析する結果とする。
parsedMetadata が空集合である場合、 true を返す。
metadata を、 parsedMetadata から最強のメタデータを取得する結果とする。
metadata 内の各 item について：
1. algorithm を item["alg"] とする。
2. expectedValue を item["val"] とする。
3. actualValue を、algorithm を bytes に適用する結果とする。
4. actualValue が expectedValue と大文字小文字を区別して一致する場合、true を返す。
false を返す。

このアルゴリズムにより、ユーザーエージェントは複数の有効で強いハッシュ関数を受け入れられる。たとえば、開発者は次のような script 要素を書くかもしれない：

<script src="https://example.com/example-framework.js"
        integrity="sha384-Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7
                   sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
        crossorigin="anonymous"></script>

これにより、ユーザーエージェントは 2 つの異なるコンテンツペイロードを受け入れられる。その一方は最初の SHA-384 ハッシュ値と一致し、もう一方は 2 番目の SHA-384 ハッシュ値と一致する。

注: ユーザーエージェントは、ユーザー設定、ブックマークレット、ユーザーエージェントへのサードパーティ追加機能、およびその他のそのような仕組みによって、ユーザーがこのアルゴリズムの結果を変更できるようにしてもよい。たとえば、HTTPS Everywhere のような拡張機能によって生成されるリダイレクトは、リソースの HTTPS 版が HTTP 版と異なっていても、正しく読み込まれ実行される可能性がある。

注: Subresource Integrity は CORS を必要とし、 CORS なしでこれを使用しようとすることは論理エラーである。ユーザーエージェントには、この失敗を説明する警告メッセージを開発者コンソールに報告することが奨励される。[Fetch]

3.4. HTML 文書サブリソースの検証

さまざまな HTML 要素は、文書に埋め込まれる、またはそのコンテキストで実行されるリソースへのリクエストを発生させる。これらの要素の一部で完全性メタデータをサポートするため、link 要素および script 要素のコンテンツ属性のリストに新しい integrity 属性が追加される。[HTML]

注: この仕様の将来の改訂では、すべての可能なサブリソース、すなわち a、audio、embed、 iframe、img、 link、object、script、source、track、および video 要素に対する完全性サポートが含まれる可能性が高い。

3.5. `integrity` 属性

integrity 属性は、要素の完全性メタデータを表す。属性の値は、空文字列、または次の ABNF 文法で説明される少なくとも 1 つの有効なメタデータのいずれかでなければならない：

integrity-metadata = *WSP hash-with-options *(1*WSP hash-with-options ) *WSP / *WSP
hash-with-options  = hash-expression *("?" option-expression)
option-expression  = *VCHAR
hash-expression    = hash-algorithm "-" base64-value

option-expression は hash-expression ごとに関連付けられ、それに直前する hash-expression にのみ適用される。

ユーザーエージェントが将来のオプションと完全に前方互換であり続けるため、ユーザーエージェントは認識できないすべての option-expression を無視しなければならない。

注: option-expression は構文内で予約されているが、オプションは定義されていないことに注意。この仕様の将来の版ではオプションについてより具体的な構文を定義する可能性が高いため、ここでは可能な限り広く定義されている。

3.6. `integrity` リンク処理オプション

完全性メタデータは、要素上の integrity 属性に適用されるものと同じ integrity-metadata 文法を使用して指定されなければならない integrity リンクパラメーターとして、 `link` HTTP レスポンスヘッダーにも指定できる。たとえば：

Link: </style.css>; rel=preload; as=style;  crossorigin="anonymous"; integrity="sha256-[digest goes here]"

3.7. 完全性違反の処理

ユーザーエージェントは、完全性検査に失敗したレスポンスのレンダリングまたは実行を拒否し、代わりに Fetch で定義されるネットワークエラーを返す。[Fetch]

注: 完全性検査に失敗すると、error イベントが発火される。正規のフォールバックリソース（たとえば、CDN から提供されないリソース、おそらく二次的で信頼できるがより遅いソースからのリソース）を提供したい開発者は、この error イベントを捕捉し、失敗したリソースを別のものに置き換える適切なハンドラーを提供できる。

3.8. Integrity-Policy

Integrity-Policy および Integrity-Policy-Report-Only HTTP ヘッダーは、文書が読み込む特定の宛先のすべてのサブリソースについて、完全性メタデータ要件に関するポリシーを適用できるようにする。

ヘッダーの値は Dictionary [RFC9651] であり、すべての member-value は inner list of tokens である。

ソースは文字列である。それに可能な唯一の値は "inline" である。

宛先は宛先型である。それに可能な値は "script" および "style" である。

完全性ポリシーは、次を含む構造体である：

sources、 source のリスト。初期値は空。
blocked destinations、destination のリスト。初期値は空。
endpoints、文字列のリスト。初期値は空。

ヘッダーリスト headers とヘッダー名 headerName を伴って、完全性ポリシーを処理するときは、次を行う：

integrityPolicy を新しい完全性ポリシーとする。
dictionary を、 headers から headerName と "dictionary" が与えられて構造化フィールド値を取得する結果とする。
dictionary["sources"] が存在しない場合、またはその値が "inline" を含む場合、"inline" を integrityPolicy の sources に付加する。
dictionary["blocked-destinations"] が存在する場合：
1. その値が "script" を含む場合、 "script" を integrityPolicy の blocked destinations に付加する。
2. その値が "style" を含む場合、 "style" を integrityPolicy の blocked destinations に付加する。
dictionary["endpoints"] が存在する場合：
1. integrityPolicy の endpoints を dictionary['endpoints'] に設定する。
integrityPolicy を返す。

次のヘッダーブロックは、完全性メタデータなしで読み込まれる任意の外部スクリプト（または任意の no-CORS 外部スクリプト）へのリクエストをブロックする。

Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)

このブロックは、"integrity-endpoint" 報告エンドポイント（関連する Reporting-Endpoints ヘッダーによって定義される）への報告もトリガーする。

開発者は、"integrity-violation" に対する ReportingObserver を登録して、 JavaScript ベースの報告を取得することもできる。

3.8.1. Integrity-Policy ヘッダーを構文解析する

Response response およびポリシーコンテナー container が与えられて、 Integrity-Policy ヘッダーを構文解析するには、次を行う：

headers を response のヘッダーリストとする。
headers が integrity-policy を含む場合、対応するヘッダー値を伴って完全性ポリシーを処理することを実行した結果を、 container の完全性ポリシーに設定する。
headers が integrity-policy-report-only を含む場合、対応するヘッダー値を伴って完全性ポリシーを処理することを実行した結果を、 container の報告専用完全性ポリシーに設定する。

3.8.2. リクエストは Integrity Policy によってブロックされるべきか

request request が与えられて、リクエストは完全性ポリシーによってブロックされるべきかを決定するには、次を行う：

policyContainer を request のポリシーコンテナーとする。
parsedMetadata を、 request の完全性メタデータを伴ってメタデータを構文解析するを呼び出した結果とする。
parsedMetadata が空集合でなく、 request のmode が "cors" または "same-origin" のいずれかである場合、 "Allowed" を返す。
request のurl がローカルである場合、 "Allowed" を返す。
policy を policyContainer の完全性ポリシーとする。
reportPolicy を policyContainer の報告専用完全性ポリシーとする。
policy と reportPolicy の両方が空の完全性ポリシーである場合、"Allowed" を返す。
global を、request のclient のグローバルオブジェクトとする。
global が Window でも WorkerGlobalScope でもない場合、"Allowed" を返す。
block を boolean とし、初期値を false とする。
reportBlock を boolean とし、初期値を false とする。
policy の sources が "inline" を含み、かつ policy の blocked destinations が request のdestinationを含む場合、 block を true に設定する。
reportPolicy の sources が "inline" を含み、かつ reportPolicy の blocked destinations が request のdestinationを含む場合、 reportBlock を true に設定する。
block が true または reportBlock が true である場合、 request、block、reportBlock、policy および reportPolicy を伴って違反を報告する。
block が true である場合は "Blocked" を返し、そうでなければ "Allowed" を返す。

3.8.3. 違反を報告する

dictionary IntegrityViolationReportBody : ReportBody {
  USVString documentURL;
  USVString blockedURL;
  USVString destination;
  boolean   reportOnly;
};

Request request、boolean block、 boolean reportBlock、完全性ポリシー policy、および完全性ポリシー reportPolicy が与えられて違反を報告するには、次を行う：

表明： request のclient は null でない。
settingsObject を request のclientとする。
global を settingsObject のグローバルオブジェクトとする。
表明： global は Window または WorkerGlobalScope である。
url を null とする。
global が Window である場合、 url を global の関連付けられた Document の URL に設定する。
global が WorkerGlobalScope である場合、 url を global のURL に設定する。
表明： url はURLである。
documentURL を、url に対して報告で使用するために URL を剥ぎ取る結果とする。
blockedURL を、 request のURLに対して報告で使用するために URL を剥ぎ取る結果とする。
block が true である場合、policy のendpoints 内の各 endpoint について：
1. body を、次のように初期化された新しい IntegrityViolationReportBody とする：
  
  documentURL
  
  documentURL
  
  blockedURL
  
  blockedURL
  
  destination
  
  request のdestination
  
  reportOnly
  
  false
2. 次の引数で報告を生成してキューに入れる：
  
  context
  
  settingsObject
  
  type
  
  "integrity-violation"
  
  destination
  
  endpoint
  
  data
  
  body
reportBlock が true である場合、reportPolicy のendpoints 内の各 endpoint について：
1. reportBody を、次のように初期化された新しい IntegrityViolationReportBody とする：
  
  documentURL
  
  documentURL
  
  blockedURL
  
  blockedURL
  
  destination
  
  request のdestination
  
  reportOnly
  
  true
2. 次の引数で報告を生成してキューに入れる：
  
  context
  
  settingsObject
  
  type
  
  "integrity-violation"
  
  destination
  
  endpoint
  
  data
  
  reportBody

4. プロキシ

レスポンスを変更する最適化プロキシおよびその他の中間サーバーは、それらのレスポンスに関連付けられたダイジェストが新しいコンテンツと同期したままであることを保証しなければならない。 1 つの選択肢は、リソースに関連付けられた完全性メタデータが更新されることを保証することである。別の選択肢は、ページ作者が完全性検証を要求したリソースについては、単にリソースの正規版だけを配信することである。

中間サーバーに情報を伝えるため、それらのリソースを提供する側は、リソースとともに、値が no-transform である Cache-Control ヘッダーを送信すべきである。

5. セキュリティおよびプライバシーに関する考慮事項

この節は規範的ではない。

5.1. 非セキュアなコンテキストは非セキュアなままである

HTTP ページなど、Secure Context でないコンテキストによって配信される完全性メタデータは、外部リソースがホストされているサーバーの侵害からオリジンを保護するだけである。ネットワーク攻撃者は、ハッシュが検証するはずのレスポンスを改変できるのと同じように、転送中のダイジェストを改変できる（または完全に削除できる、あるいは文書に対してまったく何でもできる）。したがって、作者は完全性メタデータを Secure Context にのみ配信することが推奨される。Securing the Web も参照。

5.2. ハッシュ衝突攻撃

ダイジェストの強度は、それを生成するために使用されるハッシュ関数の強度に依存する。ユーザーエージェントは、既知の弱いハッシュ関数のサポートを拒否し、サポートするアルゴリズムを衝突耐性があると知られているものに限定することが推奨される。推奨されないハッシュ関数の例には MD5 および SHA-1 が含まれる。執筆時点では、 SHA-384 がよい基準である。

さらに、ユーザーエージェントはサポートするハッシュ関数を定期的に再評価し、安全でないことが示された関数のサポートを非推奨にすることが推奨される。時間の経過とともに、ハッシュ関数は予想よりはるかに弱いことが示される可能性があり、場合によっては破られる可能性もあるため、ユーザーエージェントがこれらの進展を把握し続けることが重要である。

5.3. クロスオリジンデータ漏えい

この仕様は、完全性で保護されたクロスオリジンリクエストが CORS プロトコルを使用し、リソースのコンテンツがリクエスト元と明示的に共有されていることを保証することを要求する。この要件が省略された場合、攻撃者は同一オリジンポリシーに違反し、クロスオリジンリソースが特定のコンテンツを持つかどうかを判断できる。

攻撃者は既知のダイジェストでリソースを読み込もうとし、読み込み失敗を監視するだろう。読み込みが失敗した場合、攻撃者はレスポンスがハッシュと一致しなかったと推測でき、それによってその内容に関する何らかの洞察を得られる。これは、たとえばユーザーが特定のサービスにログインしているかどうかを明らかにする可能性がある。

さらに、攻撃者は、それ以外は静的なリソース内の特定の値をブルートフォースできる。次のような JSON レスポンスを考える：

{"status": "authenticated", "username": "admin"}

攻撃者は、さまざまな一般的なユーザー名を持つレスポンスのハッシュを事前計算し、文書の読み込みを繰り返し試みながらそれらのハッシュを指定できる。読み込みに成功すると、攻撃者がユーザー名を正しく推測したことが確認される。

6. 謝辞

ここにある内容の多くは、Gervase Markham の Link Fingerprints の概念、および WHATWG の Link Hashes に大きく触発されている。

この仕様の初期版への貴重な貢献について Mike West に特別な感謝を述べる。また、貴重なフィードバックを提供してくれた Brad Hill、Anne van Kesteren、Jonathan Kingston、Fatih Kilic、Mark Nottingham、Sergey Shekyan、Dan Veditz、Eduardo Vela、 Tanvi Vyas、Yoav Weiss、および Michal Zalewski に感謝する。

サブリソース完全性

要約

この文書の状態

1. 序論

1.1. 目標

1.2. ユースケース/例

1.2.1. リソース完全性

2. 主要な 概念と用語

2.1. 文法上の概念

3. フレームワーク

3.1. 完全性メタデータ

3.2. 暗号学的ハッシュ関数

3.2.1. 俊敏性

3.2.2. 優先度

3.3. レスポンス検証アルゴリズム

3.3.1. algorithm を bytes に適用する

3.3.2. メタデータを構文解析する

3.3.3. set から最強のメタデータを取得する

3.3.4. bytes は metadataList と一致するか？

3.4. HTML 文書サブリソースの検証

3.5. integrity 属性

3.6. integrity リンク処理オプション

3.7. 完全性違反の処理

3.8. Integrity-Policy

3.8.1. Integrity-Policy ヘッダーを構文解析する

3.8.2. リクエストは Integrity Policy によってブロックされるべきか

3.8.3. 違反を報告する

4. プロキシ

5. セキュリティおよびプライバシーに関する考慮事項

5.1. 非セキュアなコンテキストは非セキュアなままである

5.2. ハッシュ衝突攻撃

5.3. クロスオリジンデータ漏えい

6. 謝辞

適合性

文書の 表記規約

適合 アルゴリズム

索引

この仕様で定義される用語

参照によって定義される用語

参考文献

規範的参考文献

参考情報の参考文献

IDL 索引