W3C

下位資源の完全性 — Subresource Integrity

2016 年 6 月 23 日付 W3C 勧告

このバージョン
http://www.w3.org/TR/2016/REC-SRI-20160623/
最新発行バージョン
http://www.w3.org/TR/SRI/
編集者草案
https://w3c.github.io/webappsec-subresource-integrity/
実装報告
https://github.com/w3c/webappsec-subresource-integrity/wiki/Links
以前のバージョン
http://www.w3.org/TR/2016/PR-SRI-20160510/
編集
Devdatta Akhawe, Dropbox, Inc., dev.akhawe@gmail.com
Frederik Braun, Mozilla, fbraun@mozilla.com
François Marier, Mozilla, francois@mozilla.com
Joel Weinberger, Google, Inc., jww@google.com
Participate:
We are on Github.
File a bug.
Commit history.
Mailing list: public-webappsec@w3.org (subscribe)

この文書に対する修正があれば 正誤表 に掲載されます。 Please note there may be errata for this document.

英語版のみがこの仕様の規範的バージョンです。 各国語翻訳(非規範的) The English version of this specification is the only normative version. Non-normative translations may also be available.

Copyright © 2014-2016 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

要約

この仕様は、~UAが,自身が~fetchした資源が[ 期待されない操作を伴わずに送達された ]かどうか検証0できるようにする仕組みを定義する。 ◎ This specification defines a mechanism by which user agents may verify that a fetched resource has been delivered without unexpected manipulation.

この文書の位置付け

この節では、発行時点における… 【 以下,この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

この文書に対する変更点は、冒頭に示した Github ~pageから見出せます。 ◎ A list of changes to this document may be found at https://github.com/w3c/webappsec-subresource-integrity.

この文書は Web Application Security Working Group により勧告として~~発行されました。 コメントがあれば冒頭に示した Mailing list 宛に寄せられるよう願います。 ◎ This document was published by the Web Application Security Working Group as a Recommendation. If you wish to make comments regarding this document, please send them to public-webappsec@w3.org (subscribe, archives) with [SRI] at the start of your email's subject. All comments are welcome.

W3C は、この勧告に指定される機能性は, Fetch 仕様 に対する変更からは影響されないものと期待しています。 Working Group は、この仕様に~~影響を及ぼすような Fetch 仕様とその課題を追跡し続けることになります。 ◎ W3C expects the functionality specified in this Recommendation will not be affected by changes to Fetch. The Working Group will continue to track the Fetch specification and document issues that impact this specification.

1. 序論

~INFORMATIVE

~web上の~siteや~appが,単独の生成元のみからの資源で構成されることは稀である。 例えば,作者は、多様な[ ~service/ ~CDN ( Content Delivery Network, “内容~送達~network” ) ]から,~scriptや~stylesheetを~pullする — 作者は、送達された表現が[ 読込まれるものと自身が期待するものと,~~実際に~~相違ない ]ことを信用し~MUST。 攻撃者が,敵対的~serverからの内容を~downloadするよう 利用者を騙せる場合( DNS 汚染, その他の手段を介して)、作者にできる手立てはない。 同様に、~CDN~server上の~fileを置換できる攻撃者は,任意の内容を注入できる能を有する。 ◎ Sites and applications on the web are rarely composed of resources from only a single origin. For example, authors pull scripts and styles from a wide variety of services and content delivery networks, and must trust that the delivered representation is, in fact, what they expected to load. If an attacker can trick a user into downloading content from a hostile server (via DNS poisoning, or other such means), the author has no recourse. Likewise, an attacker who can replace the file on the Content Delivery Network (CDN) server has the ability to inject arbitrary content.

この~riskの一部は、資源を保安的~channel — TLS, HSTS, pinned public keys — を通じて送達することで 軽減される。 ~UAは、自身が通話相手と信じる~serverが~~本物であることについて,相応の~~確証を得られるので。 しかしながら,これらの仕組みが認証するのは、内容ではなく~serverに限られる。 ~serverへの~accessを有する攻撃者(あるいは管理者)は、咎め無く内容を操作できる。 理想は、作者が~serverの~keyを~pin†できるのみならず,内容についても資源~表現の~~同一性が確保されるよう~pinして,そのような表現に限って読込んで実行できるようにすることである。 ◎ Delivering resources over a secure channel mitigates some of this risk: with TLS, HSTS, and pinned public keys, a user agent can be fairly certain that it is indeed speaking with the server it believes it’s talking to. These mechanisms, however, authenticate only the server, not the content. An attacker (or administrator) with access to the server can manipulate content with impunity. Ideally, authors would not only be able to pin the keys of a server, but also pin the content, ensuring that an exact representation of a resource, and only that representation, loads and executes.

【† “~keyを~pinする” — 相手( ~server )の身元を随時確認できるよう,その証明情報の “真正な写し” ( ~key )を手元( ~UA側)に “ピン留め” しておく。 (したがって、(万全を期すためには)最初に “写し” を得る段階で,その真正性が確保される必要がある。)

この文書は、そのような検証の枠組みを指定する。 また、二つの~HTML要素 — `script$e, `link$e — を `integrity$a 属性で拡張する。 この属性は、作者が読込むものと期待する資源の表現に対する,暗号用~hashを包含する。 具体例として、作者は[ ある~frameworkを,自前の生成元では~hostせずに 共用~serverから読込みたい ]と望んでいるとする。 `https://example.com/example-framework.js^s に期待される `SHA-384$hS ~hashとして`~digest$ `Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7^s を指定することは、~UAが、その~URLから読込む~dataが包含している~JSを実行する前に,~dataが期待されている~hashに合致するかどうか検証0できることを意味する。 この完全性~検証0は、攻撃者により資源が悪意的な内容に置換えられる~riskを,有意に抑制する。 ◎ This document specifies such a validation scheme, extending two HTML elements with an integrity attribute that contains a cryptographic hash of the representation of the resource the author expects to load. For instance, an author may wish to load some framework from a shared server rather than hosting it on their own origin. Specifying that the expected SHA-384 hash of https://example.com/example-framework.js is Li9vy3DqF8tnTXuiaAJuML3ky+er10rcgNR/VqsVpcw+ThHmYcwiB1pbOxEbzJr7 means that the user agent can verify that the data it loads from that URL matches that expected hash before executing the JavaScript it contains. This integrity verification significantly reduces the risk that an attacker can substitute malicious content.

例えば `script^e 要素に次の様に~hashを追加すれば、 ~UAへ向けて ~hashを通信できる: ◎ This example can be communicated to a user agent by adding the hash to a script element, like so:

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

無論、~scriptだけが 完全性~検証からの便益を得られる応答~種別ではない。 ここで指定される枠組みは、 `link^e にも適用され、また,この仕様の将来の~versionでは、対象範囲を拡大する見込みが高い。 ◎ Scripts, of course, are not the only response type which would benefit from integrity validation. The scheme specified here also applies to link and future versions of this specification are likely to expand this coverage.

1.1. 目標

  1. 第三者主体~serviceが弱体化されても,自動的に その~scriptを含む~siteまで ことごとく弱体化されるべきでない。 内容~作者が、自身が読込む内容に対する期待を指定できる仕組みを与える — 例えば、当の~URLにたまたま あてがわれた ~~任意の ~scriptではなく,特定の ~scriptに限って読込めるような。 ◎ Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts. Content authors will have a mechanism by which they can specify expectations for content they load, meaning for example that they could load a specific script, and not any script that happens to have a particular URL.
  2. 検証0の仕組みは、受信された応答が妥当でないときは,それを作者に伝えるような、~errorを報告する機能性を備えるべきである。 ◎ The verification mechanism should have error-reporting functionality which would inform the author that an invalid response was received.

1.2. 利用事例と例

1.2.1 資源の完全性

  • 作者は、全世界の利用者のために処理能を改善するため,~CDNを利用したいと望んでいるとする。 しかしながら、[ ~CDNの~serverが,作者が期待する~codeのみを送達する ]ことを確保することも重要である。 ~CDNが弱体化されて(あるいは期待されない悪意的な挙動により),~siteが不幸な~~形に変えられてしまう~riskを軽減するためには、~pageに含まれる `link$e 要素に,次の`完全性~metadata$を追加する: ◎ An author wishes to use a content delivery network to improve performance for globally-distributed users. It is important, however, to ensure that the CDN’s servers deliver only the code the author expects them to deliver. To mitigate the risk that a CDN compromise (or unexpectedly malicious behavior) would change that site in unfortunate ways, the following integrity metadata is added to the link element included on the page:

    <link rel="stylesheet" href="https://site53.example.net/style.css"
          integrity="sha384-`…( ~digest )…$V"
          crossorigin="anonymous">
    
  • 作者は、第三者主体が解析~service用に提供した~JSを~pageに含めるよう求めているとする。 注意深く考査された~codeのみ 実行されることを確保するためには、~scriptに対する`完全性~metadata$を生成して,それを `script$e 要素に追加する: ◎ An author wants to include JavaScript provided by a third-party analytics service. To ensure that only the code that has been carefully reviewed is executed, the author generates integrity metadata for the script, and adds it to the script element:

    <script src="https://analytics-r-us.example.com/v1.0/include.js"
            integrity="sha384-`…( ~digest )…$V"
            crossorigin="anonymous"></script>
    
  • ~UAは、高特権の~HTML文脈(例えば, ~browserの新たな~tab~page)内で走っている~JS~codeが,表示される前に操作されないことを確保したいと望む。 `完全性~metadata$は、改ざんされた~JSが そのような高特権の文脈~下で走る~riskを軽減する。 ◎ A user agent wishes to ensure that JavaScript code running in high-privilege HTML contexts (for example, a browser’s New Tab page) aren’t manipulated before display. Integrity metadata mitigates the risk that altered JavaScript will run in these pages’ high-privilege contexts.

2. 適合性

【 この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

2.1. ~~主要な概念と各種用語

この節では、文書~全体を通して利用されるいくつかの用語を定義する。 ◎ This section defines several terms used throughout the document.

用語 `~digest@ は、任意の~data~blockに暗号用~hash関数を適用した結果を~base64に符号化した結果を指す。 ◎ The term digest refers to the base64-encoded result of executing a cryptographic hash function on an arbitrary block of data.

用語 `生成元@ は、 `RFC6454$r にて定義される。 ◎ The term origin is defined in the Origin specification. [RFC6454]

資源の[ `表現~data$, `内容~符号法$( `Content-Encoding$h ) ]は、 `RFC7231$r にて定義される。 ◎ The representation data and content encoding of a resource are defined by RFC7231, section 3. [RFC7231]

`~base64符号化法@ は、 `RFC4648$r 4 節にて定義される。 ◎ A base64 encoding is defined in RFC 4648, section 4. [RFC4648]

`SHA-256^hS, `SHA-384^hS, `SHA-512^hS は、暗号用~hash関数 `SHA-2@hS の一部を成し、 NIST “FIPS PUB 180-4: Secure Hash Standard (SHS)” にて定義される。 ◎ The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of cryptographic hash functions defined by the NIST in “FIPS PUB 180-4: Secure Hash Standard (SHS)”.

2.2. 文法上の概念

【 この節の内容は、関連する節に直に記すことにする。 】 ◎ The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC5234. [ABNF] ◎ Appendix B.1 of [ABNF] defines VCHAR (printing characters). ◎ WSP (white space) characters are defined in Section 2.4.1 Common parser idioms of the HTML 5 specification as White_Space characters.

3. ~framework

ここで指定する 完全性~検証0の仕組みは、次の処理-を煮詰める:

  • 資源から ~~十分に強い暗号用~digestを生成する。
  • 生成した~digestを,応答を検証0するために利用できるよう,~UAへ伝送する。
◎ The integrity verification mechanism specified here boils down to the process of generating a sufficiently strong cryptographic digest for a resource, and transmitting that digest to a user agent so that it may be used to verify the response.

3.1. 完全性~metadata

応答の完全性を検証0するため、~UAは, 要請の一部 として, `完全性~metadata@ を要求する。 この~metadataは、次の情報~片からなる: ◎ To verify the integrity of a response, a user agent requires integrity metadata as part of the request. This metadata consists of the following pieces of information:

  • 暗号用~hash関数( `alg@P )
  • `~digest$( `val@P )
  • 各種~option( `opt@P )
◎ cryptographic hash function (“alg”) digest (“val”) options (“opt”)

これらのうち,~hash関数と~digestは、提供され~MUST — 応答の完全性を検証するためには必須なので。 ◎ The hash function and digest MUST be provided in order to validate a response’s integrity.

注記: 現時点では,定義-済みの~optionはないが、この仕様の将来の~versionにて~optionは定義され得る — MIME 型 `MIMETYPE$r など。 ◎ At the moment, no options are defined. However, future versions of the spec may define options, such as MIME types [MIMETYPE].

この~metadataは、~CSP ~source~list構文~節 の `hash-source$P と同じ形式に符号化され~MUST(ただし、一重引用符は含めない)。 ◎ This metadata MUST be encoded in the same format as the hash-source (without the single quotes) in section 4.2 of the Content Security Policy Level 2 specification.

例えば、~script資源の内容が文字列 `alert(\'Hello, world.\');^l で,作者が~hash関数として `SHA-384$hS を選んだなら、~base64に符号化された結果の~digestは、 `H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO^s になる。 これは、次のように符号化できる: ◎ For example, given a script resource containing only the string alert(\'Hello, world.\');, an author might choose SHA-384 as a hash function. H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO is the base64-encoded digest that results. This can be encoded as follows:

sha384-H8BRh8j48O9oYatfu5AZzq6A9RINhZO5H16dQZngK7T62em8MUt1FLm52t+eX6xO

注記: ~digestを生成するために利用できる~utilityは、いくつもある。 例えば OpenSSL は、ごく共通的に可用である。 この節の例は、次の~command-lineによる結果である: ◎ Digests may be generated using any number of utilities. OpenSSL, for example, is quite commonly available. The example in this section is the result of the following command line:

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

3.2. 暗号用~hash関数

適合的~UAは、要請の`完全性~metadata$の一部として利用する暗号用~hash関数として `SHA-256$hS, `SHA-384$hS, `SHA-512$hS を~supportし~MUST。 また、追加の~hash関数も~supportして~MAY。 ◎ Conformant user agents MUST support the SHA-256, SHA-384 and SHA-512 cryptographic hash functions for use as part of a request’s integrity metadata and MAY support additional hash functions.

~UAは、自身が~supportする~hashing関数を,次にしたがって制約する~SHOULDである( ~hash衝突~攻撃 を見よ):

  • `MD5^hS や `SHA-1^hS の様な弱いことが既知のものは~supportしない。
  • 衝突耐性があることが既知のものに限る。
  • ~supportしている~hashing関数を定期的に再評価して、保安的でなくなったものは非推奨にする。
◎ User agents SHOULD refuse to support known-weak hashing functions like MD5 or SHA-1 and SHOULD restrict supported hashing functions to those known to be collision-resistant. Additionally, user agents SHOULD re-evaluate their supported hash functions on a regular basis and deprecate support for those functions that have become insecure. See Hash collision attacks.

3.2.1. 即応性

将来,暗号上の発見に直面したときに 機敏に対応できるよう、同じ資源に,`完全性~metadata$の集合が複数個†結付けられてもよい。 ◎ Multiple sets of integrity metadata may be associated with a single resource in order to provide agility in the face of future cryptographic discoveries. For example, the resource described in the previous section may be described by either of the following hash expressions:

作者は、同じ資源に対し,例えば `SHA-384$hS, `SHA-512$hS ~hashの二つを指定してよい: ◎ sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd ◎ sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw== ◎ Authors may choose to specify both, for example:

<script src="hello_world.js"
   integrity="sha384-`…( ~digest )…$V
              sha512-`…( ~digest )…$V"
   crossorigin="anonymous"></script>

【† 集合が複数個( multiple sets of 〜 ) — すなわち、各~hash関数ごとにも,複数の~hash値を与えれる( 後述の例 )。 】

この事例では、~UAは,応答を検証するときに~list内の最も強い~hash関数を選んで, その~metadataを利用することになる(後述の “%~metadata を`構文解析-$する” / “%集合 から`最も強い~metadataを取得-$する” に則って)。 ◎ In this case, the user agent will choose the strongest hash function in the list, and use that metadata to validate the response (as described below in the “parse metadata” and “get the strongest metadata from set” algorithms).

非保安的と決定された~hash関数に対しては、~UAは,それを非推奨にした上で、最終的には,非保安的な~hash関数を利用している完全性~検証の~supportを除去する~SHOULDである。 ~UAは、応答の妥当性を検査する際に,非推奨にされた関数に基づく~digestを利用して~MAY。 ◎ When a hash function is determined to be insecure, user agents SHOULD deprecate and eventually remove support for integrity validation using the insecure hash function. User agents MAY check the validity of responses using a digest based on a deprecated function.

作者が,古い~UAに縛られることなく より強い~hash関数に切替えれるよう、~UAは,自身が~supportしない~hash関数を利用している検証に対しては,その完全性~値は提供されなかったかの様に動作することになる(後述の, %応答 は %~metadata~list に合致するか? を見よ)。 作者には、強い~hash関数を利用することに加え,より強い~hash関数が可用になり次第 それへ移行することが奨励される。 ◎ To allow authors to switch to stronger hash functions without being held back by older user agents, validation using unsupported hash functions acts like no integrity value was provided (see the “Does response match metadataList” algorithm below). Authors are encouraged to use strong hash functions, and to begin migrating to stronger hash functions as they become available.

3.2.2. 優先度

~UAは、[ 2 個の~hash関数 %A, %B に対し,[ どちらか優先される方, あるいは 優先度が等しい場合は空~文字列 ]を返す仕組み — 以下では `getPrioritizedHashFunction@( %A, %B ) と記される関数 — を提供し~MUST。 それは,~UAが最も衝突耐性があると見なす~hash関数を返す。 例えば、 `getPrioritizedHashFunction$(`sha256^l, `sha512^l) は, `sha512^l を返し、 `getPrioritizedHashFunction$(`sha256^l, `sha256^l) は,空~文字列を返すことになる。 ◎ User agents must provide a mechanism for determining the relative priority of two hash functions and return the empty string if the priority is equal. That is, if a user agent implemented a function like getPrioritizedHashFunction(a, b) it would return the hash function the user agent considers the most collision-resistant. For example, getPrioritizedHashFunction('sha256', 'sha512') would return 'sha512' and getPrioritizedHashFunction('sha256', 'sha256') would return the empty string.

注記: `getPrioritizedHashFunction$ は、内部的な実装の詳細であり,実装者が~web~appに提供する~APIでない。 それはもっぱら、この文書にて~algoの記述を単純化するために利用される。 ◎ The getPrioritizedHashFunction is an internal implementation detail. It is not an API that implementors provide to web applications. It is used in this document only to simplify the algorithm description.

【 3 個~以上の~hash関数の優先度が循環する様な結論を導くような `getPrioritizedHashFunction$ が 明示的に禁止されていないが、そのような比較~関数は許容されないかどうかは、この仕様の他所を見ても判らない(この仕様の~algoは、そうであっても問題なく働く/働いてしまう)。 】

3.3. 応答を検証0する~algo

3.3.1. %応答 に %~algo を適用する

  1. %表現~data ~LET %応答 の`表現~data$
  2. ~IF[ ~UAは,`内容~符号法$たち( `Content-Encoding$h )を適用した上で内容を消費するものと意図する ] ⇒ %表現~data ~SET %表現~data に`内容~符号法$たちを適用した結果
  3. ~RET [ %表現~data に %~algo を`適用-$した結果 ]を~base64に符号化した結果
◎ Let result be the result of applying algorithm to the representation data without any content-codings applied, except when the user agent intends to consume the content with content-encodings applied. In the latter case, let result be the result of applying algorithm to the representation data. ◎ Let encodedResult be result of base64-encoding result. ◎ Return encodedResult.

3.3.2. %応答 は完全性~検証に適格か?

[ 攻撃者が、完全性~検査を介して値を総当たりすることにより,非同一生成元~dataを読取る能 ]を軽減するため、応答は,[ それが同一生成元である ]か, または[ `CORS$r を介して読込む生成元として,明示的に~accessが是認されている ]場合に限り,そのような検査に適格とされる。 ◎ In order to mitigate an attacker’s ability to read data cross-origin by brute-forcing values via integrity checks, responses are only eligible for such checks if they are same-origin or are the result of explicit access granted to the loading origin via Cross Origin Resource Sharing [CORS].

注記: `RFC6454$r の 4 節 に注記されているように、~UAには,`file^sc ~scheme~URLに対し大域一意~識別子を利用するものもある。 そのような~UAにおいては、 `file^sc ~scheme~URLを通じて~accessされる資源は、完全性~検査に適格とされないことになる。 ◎ As noted in RFC6454, section 4, some user agents use globally unique identifiers for each file URI. This means that resources accessed over a file scheme URL are unlikely to be eligible for integrity checks.

注記: `保安文脈$下にあること(例:文書は~HTTPSを通じて送達された)が、完全性~検証の利用に必要とされるわけではない — 資源の完全性は、~app~levelのみの保安~toolであり,~UAの保安~状態を変更するものではないので。 しかしながら作者は、保安文脈でない何か(例: ~HTTPを通じて送達された文書)で利用された完全性【~metadata】は,保安~保証を全く提供しないことを意識しておくべきである。 この理由から、作者は,保安文脈~下に限って完全性~metadataを送達するべきである。 更なる論点は、 非保安的~文脈は非保安的であり続ける を見よ。 ◎ Being in a Secure Context (e.g., a document delivered over HTTPS) is not necessary for the use of integrity validation. Because resource integrity is only an application level security tool, and it does not change the security state of the user agent, a Secure Context is unnecessary. However, if integrity is used in something other than a Secure Context (e.g., a document delivered over HTTP), authors should be aware that the integrity provides no security guarantees at all. For this reason, authors should only deliver integrity metadata in a Secure Context. See Non-secure contexts remain non-secure for more discussion.

これらの制約の詳細は、次の~algoで与えられる: ◎ The following algorithm details these restrictions:

  1. %応答 ~LET %資源 を`~fetch$した結果の応答 ◎ Let response be the response that results from fetching the resource.
  2. ~IF[ %応答 の`種別$rs ~IN { `basic^l, `cors^l, `default^l } ] ⇒ ~RET ~T ◎ If the response type is basic, cors or default, return true.
  3. ~RET ~F ◎ Return false.

注記: 応答の`種別$rsは, `FETCH$r にて定義され、うち,上に挙げたものは次を表す: ◎ The response types are defined by the Fetch specification [FETCH] and refer to the following:

  • `basic^l は、応答が 【それを要請した資源と】 同一生成元であることを表す。 ◎ basic is a same-origin response, and thus the requestor has full access to read the body.
  • `cors^l は、~CORSが可能化された非同一生成元への要請に対する妥当な応答であることを表す。 ◎ cors is a valid response to a cross-origin, CORS-enabled request, and thus again the requestor has full access to read the body.
  • `default^l は、 Service Worker により,要請に対する応答として生成された妥当な応答であることを表す。 ◎ default is a valid response that is generated by a Service Worker as a response to the request, so its body, too, is fully readable by the requestor.

これらのいずれもに対しても、要請者は,応答の`本体$rsを全部的に読取れることになる。 ◎ ↑

3.3.3. %~metadata を構文解析する

この~algoは、所与の文字列に対し, `~metadataなし^i または[ ~UAにより解される~hash関数からなる,妥当な~hash式の集合 ]を返す: ◎ This algorithm accepts a string, and returns either no metadata, or a set of valid hash expressions whose hash functions are understood by the user agent.

【 空~集合を返す場合もある(含まれている~metadataすべてが妥当でない場合に生じる)。 `~metadataなし^i との違いは、[ %応答 は %~metadata~list に合致するか? ]の挙動に現れる。 】

  1. %結果 ~LET 空~集合 ◎ Let result be the empty set. ◎ Let empty be equal to true.
  2. %~token~list ~LET %~metadata を`~ASCII空白で分割-$した結果 ◎ ↓
  3. ~IF[ %~token~list は空~listである ] ⇒ ~RET `~metadataなし^i ◎ ↓↓
  4. ~FOR %~token~list 内の~EACH ( %~token ) に対し: ◎ For each token returned by splitting metadata on spaces:

    1. ~IF[ %~token は妥当な~metadataでない ] ⇒ ~CONTINUE ◎ Set empty to false. ◎ If token is not a valid metadata, skip the remaining steps, and proceed to the next token.
    2. %解析済~token ~SET `完全性~metadata$の文法に基づいて %~token を構文解析した結果 ◎ Parse token per the grammar in integrity metadata.
    3. %~algo ~LET %解析済~token の `alg$P 成分 ◎ Let algorithm be the alg component of token.
    4. ~IF[ %~algo は ~UAが認識する~hash関数である ] ⇒ %結果 に %解析済~token を追加する ◎ If algorithm is a hash function recognized by the user agent, add the parsed token to result.
  5. ~RET %結果 ◎ Return no metadata if empty is true, otherwise return result.

3.3.4. %集合 から最も強い~metadataを取得する

  1. %結果 ~LET 空~集合 ◎ ↓
  2. %最強~algo ~LET ~NULL ◎ Let result be the empty set and strongest be the empty string.
  3. ~FOR %集合 内の~EACH ( %~item ) に対し:

    1. %新~algo ~LET %~item の `alg$P 成分
    2. %~algo ~SET [ %最強~algo ~EQ ~NULL ならば %新~algo / ~ELSE_ `getPrioritizedHashFunction$( %最強~algo, %新~algo ) の結果 ]
    3. %~algo に応じて:

      空~文字列
      %~item を %結果 に追加する
      %新~algo
      1. %結果 ~SET 空~集合
      2. %~item を %結果 に追加する
      3. %最強~algo ~SET %新~algo
      %最強~algo
      何もしない
    ◎ For each item in set: ◎ If result is the empty set, add item to result and set strongest to item, skip to the next item. ◎ Let currentAlgorithm be the alg component of strongest. ◎ Let newAlgorithm be the alg component of item. ◎ If the result of getPrioritizedHashFunction(currentAlgorithm, newAlgorithm) is the empty string, add item to result. If the result is newAlgorithm, set strongest to item, set result to the empty set, and add item to result.
  4. ~RET %結果 ◎ Return result.

3.3.5. %応答 は %~metadata~list に合致するか?

  1. %解析済~metadata ~LET %~metadata~list を`構文解析-$した結果 ◎ Let parsedMetadata be the result of parsing metadataList.
  2. ~IF[ %解析済~metadata ~EQ `~metadataなし^i ] ⇒ ~RET ~T ◎ If parsedMetadata is no metadata, return true.
  3. ~IF[ %応答 は`完全性~検証に適格$でない ] ⇒ ~RET ~F ◎ If response is not eligible for integrity validation, return false.
  4. ~IF[ %解析済~metadata は空~集合である ] ⇒ ~RET ~T ◎ If parsedMetadata is the empty set, return true.
  5. %~metadata ~LET %解析済~metadata から`最も強い~metadataを取得-$した結果 ◎ Let metadata be the result of getting the strongest metadata from parsedMetadata.
  6. ~FOR %~metadata 内の~EACH ( %~item ) に対し: ◎ For each item in metadata:

    1. %~algo ~LET %~item の `alg$P 成分 ◎ Let algorithm be the alg component of item.
    2. `期待される値^V ~LET %~item の `val$P 成分 ◎ Let expectedValue be the val component of item.
    3. %実~値 ~LET %応答 に %~algo を`適用-$した結果 ◎ Let actualValue be the result of applying algorithm to response.
    4. ~IF[ %実~値 ~EQ `期待される値^V ] ⇒ ~RET ~T ◎ If actualValue is a case-sensitive match for expectedValue, return true.
  7. ~RET ~F ◎ Return false.

この~algoは、~UAが,複数の 妥当かつ強い~hash関数を受容できるようにする。 例えば,開発者は、 `script$e 要素を次のようにも記せる: ◎ This algorithm allows the user agent to accept multiple, valid strong hash functions. For example, a developer might write a script element such as:

<script src="https://example.com/example-framework.js"
        integrity="sha384-`…( ~digest )…$V
                   sha384-`…( ~digest )…$V"
        crossorigin="anonymous"></script>

~UAに,二つの異なる内容~payload — 最初の, および二番目の `SHA-384$hS ~hash値に合致するもの — を受容させられるようになる。 ◎ which would allow the user agent to accept two different content payloads, one of which matches the first SHA384 hash value and the other matches the second SHA384 hash value.

注記: ~UAは、利用者に,この~algoの結果を改変することを許容してよい — [ 利用者~選好, ~bookmarklet, 第三者主体による~UAに対する追加, その他の同類の仕組み ]を介して。 例えば、 HTTPS Everywhere の様な拡張により生成される~redirectは、資源の[ ~HTTPS, ~HTTP ]~versionが相違する場合でも,正しく読込んで実行する。 ◎ User agents may allow users to modify the result of this algorithm via user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms. For example, redirects generated by an extension like HTTPS Everywhere could load and execute correctly, even if the HTTPS version of a resource differs from the HTTP version.

注記: この~algoは、応答が`完全性~検証に適格$でない場合には ~F を返す — 下位資源の完全性には,~CORSが要求され、~CORSを伴わずにそれを利用しようとする試みるのは,論理的に~errorなので。 加えて,~UAは、開発者~consoleに向けて,この失敗を説明する警告~messageを報告する~SHOULDである。 ◎ This algorithm returns false if the response is not eligible for integrity validation since Subresource Integrity requires CORS, and it is a logical error to attempt to use it without CORS. Additionally, user agents SHOULD report a warning message to the developer console to explain this failure.

3.4. ~HTML文書の下位資源に対する検証0

種々の~HTML要素が,[[ 文書の中へ埋込まれるか, 文書の文脈~下で実行される ]ことになるような資源 ]を要請する。 その種の要素に対し,完全性~metadataを~supportする一環として、 `link$e / `script$e 要素には,新たな内容~属性 `integrity$a が追加される。 ◎ A variety of HTML elements result in requests for resources that are to be embedded into the document, or executed in its context. To support integrity metadata for some of these elements, a new integrity attribute is added to the list of content attributes for the link and script elements.

各~要素の `integrity$a 内容~属性を`反映-$する,対応する `integrity$m ~IDL属性が[ `HTMLLinkElement^I / `HTMLScriptElement^I ]~interfaceに追加される。 ◎ A corresponding integrity IDL attribute which reflects the value each element’s integrity content attribute is added to the HTMLLinkElement and HTMLScriptElement interfaces.

注記: この仕様の将来の改訂版は、可能0なすべての下位資源 — すなわち,次に挙げる要素 — に対しても,完全性の~supportを含める見込みが高い ⇒ `a^e, `audio^e, `embed^e, `iframe^e, `img^e, `link^e, `object^e, `script^e, `source^e, `track^e, `video^e ◎ A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

3.5. `integrity^a 属性

`integrity^a 属性は、要素に対する`完全性~metadata$を表現する。 この属性の値は、空~文字列か, または 少なくとも 1 個以上の,次の ABNF ( Augmented Backus-Naur Form, `ABNF$r ) 文法に則って妥当な~metadataを含んで~MUST ◎ The integrity attribute represents integrity metadata for an element. The value of the attribute MUST be either the empty string, or at least one valid metadata as described by the following ABNF grammar:

`integrity-metadata@P
    = *`WSP^P `hash-with-options$P *( 1*`WSP^P `hash-with-options$P ) *`WSP^P
    / *`WSP^P
`hash-with-options@P  = `hash-expression$P *("?" `option-expression$P)
`option-expression@P  = *`VCHAR^P
`hash-expression@P    = `hash-algo$P "-" `base64-value$P

`integrity$m ~IDL属性は、 `integrity$a 内容~属性を`反映-$し~MUST。

上の ABNF において:

  • `hash-algo$P, `base64-value$P は、~CSP Level 2 の ~source~list構文~節 の同名の生成規則で与えられる。
  • `WSP^P は、 HTML 仕様に定義される`~ASCII空白$を表す。
  • `VCHAR^P (印字可能~文字)は、 `ABNF$r Appendix B.1 にて定義される。
◎ hash-algo = <hash-algo production from [Content Security Policy Level 2, section 4.2]> ◎ base64-value = <base64-value production from [Content Security Policy Level 2, section 4.2]> ◎ The integrity IDL attribute must reflect the integrity content attribute.

`option-expression$P は、各 `hash-expression$P ごとに結付けられ,直前の `hash-expression$P のみに適用される。 ◎ option-expressions are associated on a per hash-expression basis and are applied only to the hash-expression that immediately precedes it.

~UAは、将来の~optionと全部的に前方互換であり続けるようにするため,自身が認識しない `option-expression$P を無視し~MUST。 ◎ In order for user agents to remain fully forwards compatible with future options, the user agent MUST ignore all unrecognized option-expressions.

注記: 構文~内では `option-expression$P が予約されているが、定義済みの~optionはまだないことに注意。 この仕様の将来の~versionでは,~optionに対しより特定的な構文を定義することになる見込みが高いので、なるべく広く定義されている。 ◎ Note that while the option-expression has been reserved in the syntax, no options have been defined. It is likely that a future version of the spec will define a more specific syntax for options, so it is defined here as broadly as possible.

3.6. 要素~interfaceに対する拡張

partial interface `HTMLLinkElement$I {
                    attribute DOMString integrity;
};

partial interface `HTMLScriptElement$I {
                    attribute DOMString integrity;
};

これらの~interfaceの `integrity^m 属性は、いずれも,当の要素の `integrity$a 属性を`反映-$する。 3.6.1 HTMLLinkElement partial interface HTMLLinkElement { attribute DOMString integrity; }; 3.6.1.1 Attributes integrity of type DOMString integrity 3.6.2 HTMLScriptElement partial interface HTMLScriptElement { attribute DOMString integrity; }; 3.6.2.1 Attributes integrity of type DOMString integrity

3.7. 完全性~違反の取扱い

~UAは、完全性~検査に失敗した応答を[ 具現化する/実行する ]のを拒否して,代わりに `FETCH$r にて定義される~network~errorを返すことになる。 ◎ The user agent will refuse to render or execute responses that fail an integrity check, instead returning a network error as defined in Fetch [FETCH].

注記: 完全性~検査の失敗-時には、 `error^et ~eventが発火される。 開発者は、正準的~fallback資源(例: ~CDNから~serveされていない, 二次的な,信用されてはいるが より低速な~sourceからの資源など)を提供したいと望むなら、[ この `error^et ~eventをとらえて,失敗した当の資源を異なるものに置換する ]ような適切な~handlerを提供できる。 ◎ On a failed integrity check, an error event is fired. Developers wishing to provide a canonical fallback resource (e.g., a resource not served from a CDN, perhaps from a secondary, trusted, but slower source) can catch this error event and provide an appropriate handler to replace the failed resource with a different one.

3.8. 要素

3.8.2. `script^e 要素

HTML5 の ~scriptを準備する~algo の段 14.1 を次の段に置換する: ◎ Replace step 14.1 of HTML5’s “prepare a script” algorithm with:

  1. %src ~LET %要素の `src^a 属性~値;
    %要請 の`完全性~metadata$ ~LET %要素 の `integrity$a 属性~値 ◎ Let src be the value of the element’s src attribute and the request’s associated integrity metadata be the value of the element’s integrity attribute.

【 この記述は、現在の HTML 仕様からずれている。 現在の仕様では、 ~scriptを準備する~algo, ~scriptの~fetch処理 に手を加えることになるであろう。 】

4. ~proxy

応答を改変するような~proxyその他の中継~serverを最適化するときは、当の応答に結付けられた~digestが新たな内容にも同期し続けることを確保し~MUST。 選択肢としては、次が挙げられる:

  • 資源に結付けらている`完全性~metadata$が更新されることを確保する。
  • 単純に,~page作者が完全性~検証0を要請した際には,当の資源の正準的~versionのみを送達する。
◎ Optimizing proxies and other intermediate servers which modify the responses MUST ensure that the digest associated with those responses stays in sync with the new content. One option is to ensure that the integrity metadata associated with resources is updated. Another would be simply to deliver only the canonical version of resources for which a page author has requested integrity verification.

中継~serverに伝わり易くするため、資源を~serveしている~serverは,自身が送信する資源に,値 `no-transform$dir を伴う `Cache-Control$h ~headerを伴わせる~SHOULDである。 ◎ To help inform intermediate servers, those serving the resources SHOULD send along with the resource a Cache-Control header with a value of no-transform.

5. 保安~上の考慮点

~INFORMATIVE

5.1 非保安的~文脈は非保安的であり続ける

[[ ~HTTP~pageなどの`保安文脈$でない文脈 ]により送達される`完全性~metadata$ ]が保護する生成元は,[ 外部~資源を~hostしている~serverの弱体化に抗する ]ことのみである。 ~network攻撃者は、~hashの検証-対象である応答を,その経路上で改ざんできるのと同じく,~~元の~digestも改ざんできる(あるいは,それを除去するなど,文書に対し何でもできる)。 したがって,作者は、完全性~metadataを`保安文脈$下でのみ送達する~SHOULDである。 ~webの保安化法 も見よ。 ◎ Integrity metadata delivered by a context that is not a Secure Context, such as an HTTP page, only protects an origin against a compromise of the server where an external resources is hosted. Network attackers can alter the digest in-flight (or remove it entirely, or do absolutely anything else to the document), just as they could alter the response the hash is meant to validate. Thus, it is recommended that authors deliver integrity metadata only to a Secure Context. See also securing the web.

5.2 ~hash衝突~攻撃

~digestの強さは、それを生成する~hash関数に基づく。 ~UAには、[ 弱いことが既知である~hashing関数に対する~supportは拒否すること ], および[ ~supportする~algoを,衝突耐性があることが既知であるものに制限すること ]が推奨される。 推奨されない~hashing関数の例としては、 `MD5^hS や `SHA-1^hS が挙げられる。 これを書いている時点では、`SHA-384$hS は 良好な~~基準である。 ◎ Digests are only as strong as the hash function used to generate them. It is recommended that user agents refuse to support known-weak hashing functions and limit supported algorithms to those known to be collision resistant. Examples of hashing functions that are not recommended include MD5 and SHA-1. At the time of writing, SHA-384 is a good baseline.

更には、~UAには,[ 定期的に,自身が~supportしている~hash関数を再評価すること ], および[ 非保安的と~~判明した関数に対しては,~supportを非推奨にすること ]が推奨される。 ~hash関数は,時を経て[ 期待されるより ずっと弱い, あるいは 一部の事例では壊れている ]ものと~~判明することがあるので、~UAは,開発にあたって そのことを意識し続けることが重要である。 ◎ Moreover, it is recommended that user agents re-evaluate their supported hash functions on a regular basis and deprecate support for those functions shown to be insecure. Over time, hash functions may be shown to be much weaker than expected and, in some cases, broken, so it is important that user agents stay aware of these developments.

5.3 非同一生成元~data漏洩

この仕様は、[ 完全性の保護-対象である非同一生成元~要請 ]に`~CORS設定群~属性$が在することを要求する。 この要件が無ければ、攻撃者は 同一生成元~施策 に違反することもできる — 以下に述べるように,非同一生成元~資源が,ある種の内容を持つかどうか決定できてしまう。 ◎ This specification requires the CORS settings attribute to be present on integrity-protected cross-origin requests. If that requirement were omitted, attackers could violate the same-origin policy and determine whether a cross-origin resource has certain content.

  • 攻撃者は、既知の~digestで資源の読込みを試みながら,その失敗を注視する。 読込みに失敗したなら、応答がその~hashに合致しないことを推測でき、それにより その内容についての洞察を得られる。 これは例えば、利用者が特定0の~serviceに~log-inしたかどうかを露呈するかもしれない。 ◎ Attackers would attempt to load the resource with a known digest, and watch for load failures. If the load fails, the attacker could surmise that the response didn’t match the hash and thereby gain some insight into its contents. This might reveal, for example, whether or not a user is logged into a particular service.
  • 更には、攻撃者は,静的な資源~内の特定の値を総当たりできる。 次の様な~JSON応答を考える: ◎ Moreover, attackers could brute-force specific values in an otherwise static resource. Consider a JSON response that looks like this:

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

    攻撃者は、様々な共通的な~usernameから,応答に対する~hashを予め算出しておいて、 それらの~hashを順々に指定しながら繰り返し文書の読込みを試みれる。 読込みに成功したなら、~usernameを正しく憶測できたことが確認されたことになる。 ◎ An attacker could precompute hashes for the response with a variety of common usernames, and specify those hashes while repeatedly attempting to load the document. A successful load would confirm that the attacker has correctly guessed the username.

謝辞

この仕様のかなりの部分は、 Gervase Markham 氏による Link Fingerprints の概念, および WHATWG による Link Hashes から着想を得ている。 ◎ Much of the content here is inspired heavily by Gervase Markham’s Link Fingerprints concept, as well as WHATWG’s Link Hashes.

この仕様の初期~versionに貴重な貢献された Google 社の Mike West 氏に特別な謝意を。 加えて,貴重な~feedbackを寄せられた次の方々にも: ◎ A special thanks to Mike West of Google, Inc. for his invaluable contributions to the initial version of this spec.

Additionally, Brad Hill, Anne van Kesteren, Jonathan Kingston, Mark Nottingham, Dan Veditz, Eduardo Vela, Tanvi Vyas, and Michal Zalewski provided invaluable feedback.

索引

【 この節の内容は省略(ウィンドウ下端の索引機能を利用されたし)。 】

参照文献

文献(規範)