Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let Fetch be in charge of extracting the bytes #97

Merged
merged 3 commits into from
Feb 22, 2021
Merged

Let Fetch be in charge of extracting the bytes #97

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7cf57a0
Let Fetch be in charge of extracting the bytes
annevk Feb 19, 2021
11704c4
grammar nit
annevk Feb 19, 2021
5b2bcd4
add back subset of note
annevk Feb 19, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 10 additions & 72 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,7 +183,7 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
</pre>
</div>

* A user agent wishes to ensure that JavaScript code running in high-privilege HTML
* 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.
<a>Integrity metadata</a> mitigates the risk that altered JavaScript will run
in these pages' high-privilege contexts.
Expand All @@ -199,10 +199,6 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180

The terms [=/origin=] and [=same origin=] are defined in HTML. [[!HTML]]

The <dfn>representation data</dfn> of a resource is defined by
<a href="https://tools.ietf.org/html/rfc7231#section-3">Section 3
of RFC 7231</a>. [[!RFC7231]]

A <dfn>base64 encoding</dfn> is defined in <a
href="https://tools.ietf.org/html/rfc4648#section-4">Section 4 of RFC 4648</a>.
[[!RFC4648]]
Expand Down Expand Up @@ -346,60 +342,10 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180

## Response verification algorithms ## {#verification-algorithms}

### Apply |algorithm| to |response| ### {#apply-algorithm-to-response}

1. Let |result| be the result of [[#apply-algorithm-to-response]]
to the <a>representation data</a> without any content-codings
applied, except when the user agent intends to consume the content with
content-codings applied. In the latter case, let |result| be
the result of applying |algorithm| to the <a>representation data</a>.
2. Let |encodedResult| be result of <a>base64 encoding</a> |result|.
3. Return |encodedResult|.

### Is |response| eligible for integrity validation? ### {#is-response-eligible}

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 [[!Fetch]].

Note: As noted in
<a href="https://tools.ietf.org/html/rfc6454#section-4">RFC6454, section 4</a>,
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.

Note: Being in a <a>Secure Context</a> (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 are reminded that the integrity provides <em>no security
guarantees at all</em>. For this reason, authors are encouraged to only deliver
integrity metadata in a Secure Context. See [[#non-secure-contexts]] for
more discussion.

The following algorithm details these restrictions:

1. Let |response| be the response that results from
<a lt="fetch">fetching</a> the |resource|.
2. If the <a>|response| type</a> is `basic`,
`cors` or `default`, return `true`.
3. Return `false`.

<div class="note">
The <a lt="response type">response types</a> are defined by the Fetch
specification [[!FETCH]] and refer to the following:

* `basic` is a <a>same origin</a> response, and thus the requestor has full access
to read the body.
* `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` 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.
### Apply |algorithm| to |bytes| ### {#apply-algorithm-to-response}

</div>
1. Let |result| be the result of applying |algorithm| to |bytes|.
2. Return the result of <a>base64 encoding</a> |result|.

### Parse |metadata| ### {#parse-metadata}

Expand Down Expand Up @@ -440,23 +386,21 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
set, and add |item| to |result|.
3. Return |result|.

### Does |response| match |metadataList|? ### {#does-response-match-metadatalist}
<h3 dfn export id=does-response-match-metadatalist>Do |bytes| match |metadataList|?</h3>

1. Let |parsedMetadata| be the result of
<a href="#parse-metadata">parsing |metadataList|</a>.
2. If |parsedMetadata| is `no metadata`, return `true`.
3. If <a href="#is-response-eligible">|response| is not eligible for integrity
validation</a>, return `false`.
4. If |parsedMetadata| is the empty set, return `true`.
5. Let |metadata| be the result of <a href="#get-the-strongest-metadata">
3. If |parsedMetadata| is the empty set, return `true`.
4. Let |metadata| be the result of <a href="#get-the-strongest-metadata">
getting the strongest metadata from |parsedMetadata|</a>.
6. For each |item| in |metadata|:
5. For each |item| in |metadata|:
1. Let |algorithm| be the |alg| component of
|item|.
2. Let |expectedValue| be the |val| component of
|item|.
3. Let |actualValue| be the result of <a
href="#apply-algorithm-to-response">applying |algorithm| to |response|
href="#apply-algorithm-to-response">applying |algorithm| to |bytes|
</a>.
4. If |actualValue| is a case-sensitive match for
|expectedValue|, return `true`.
Expand Down Expand Up @@ -485,12 +429,6 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
execute correctly, even if the HTTPS version of a resource differs from the HTTP
version.

Note: This algorithm returns `false` if the response is not <a
annevk marked this conversation as resolved.
Show resolved Hide resolved
href="#is-response-eligible">eligible</a> 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.

## Verification of HTML document subresources ## {#verification-of-html-document-subresources}

A variety of HTML elements result in requests for resources that are to be
Expand Down Expand Up @@ -562,7 +500,7 @@ spec: SHA2; urlPrefix: http://csrc.nist.gov/publications/fips/fips180-4/fips-180
## Handling integrity violations ## {#handling-integrity-violations}

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]].
check, instead returning a network error as defined in Fetch [[!Fetch]].

Note: On a failed integrity check, an `error` event is fired. Developers
wishing to provide a canonical fallback resource (e.g., a resource not served
Expand Down
Loading