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.

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

Revive require-sri-for for scripts #129

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 5 commits
Commits
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
124 changes: 121 additions & 3 deletions index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -28,9 +28,28 @@ spec: ABNF; urlPrefix: https://tools.ietf.org/html/rfc5234
type: dfn
text: VCHAR; url: appendix-B.1
text: WSP; url: appendix-B.1
text: OWS; url: appendix-B.1
type: grammar
text: VCHAR; url: appendix-B.1
text: WSP; url: appendix-B.1
text: OWS; url: appendix-B.1

spec: HTTP; urlPrefix: https://tools.ietf.org/html/rfc7230
type: dfn
text: token; url: #section-3.2.6
type: grammar
text: token; url: #section-3.2.6

spec: CSP; urlPrefix: https://w3c.github.io/webappsec-csp/
type: dfn
text: Content Security Policy; urlPrefix: #
text: policy; url: policy
text: directive; url: directives
text: value; for: directive; url: directive-value
text: pre-request check; url: directive-pre-request-check
text: create a violation object for global; url: create-violation-for-global
text: report violation; url: report-violation
text: disposition; for: policy

spec: RFC7234; urlPrefix: https://tools.ietf.org/html/rfc7234
type: dfn
Expand Down Expand Up @@ -203,8 +222,6 @@ spec:csp3; type:grammar; text:base64-value
Content Security Policy defines the <a grammar>`base64-value`</a> and
<a grammar>`hash-algorithm`</a> rules. [[!CSP]]

</section>

<!-- ####################################################################### -->

# Framework # {#framework}
Expand Down Expand Up @@ -322,7 +339,97 @@ spec:csp3; type:grammar; text:base64-value
supported by this specification.


## Response verification algorithms ## {#verification-algorithms}
## Request verification algorithms ## {#request-verification-algorithms}

### Opting-in ### {#opt-in-require-sri-for}

Authors may opt a {{Document}} to require SRI metadata be present for
some resource types via a <dfn export>require-sri-for</dfn> <a>Content
Security Policy</a> directive defined by the following ABNF grammar:

<pre dfn-type="grammar" link-type="grammar">
directive-name = "require-sri-for"
directive-value = <a grammar>token</a> *( <a>OWS</a> <a>token</a> )
</pre>

The following list contains the set of <dfn noexport>known tokens</dfn>:

* `script` requires SRI for scripts


### Parsing `require-sri-for` ### {#parse-require-sri-for}

Given a string (|token list|), this algorithm returns a list of resource
types which will require integrity checks:

1. Let |protected resource types| be the empty <a for=/>set</a>.

2. For each |token| in the result of <a lt="split a string on ascii whitespace">
splitting |token list| on spaces</a>, if token matches the grammar
for <a>require-sri-for</a> and is a <a>ASCII case-insensitive match</a>
for any of the <a>known token</a>s, add |token| to |protected resource types|.
Otherwise, ignore the token.

3. Return the set of |protected resource types|.

Comment on lines +360 to +374
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How likely is it that we expand the list of known tokens? Otherwise a simple string-equals match would suffice.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously the list also included "style". As I don't have a clear use case for it, I didn't add it here.

We could drop this to be a simple equality check now, and expand to a list if/when the time comes.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should the behavior be in user agents which don't understand the new type?

This suggestion would make them not enforce anything at all, which seems suboptimal?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the way CSP directives are currently defined, and that enabled us to expand them over time.

Not enforcing anything on unknown types would enable us to expand the list overtime if needed. What's the alternative you see?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking through @annevk's other comment, workers may be a good candidate for near-future expansion of the list.

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

This directive’s <a>pre-request check</a> is as follows:

Given a <a for="/">request</a> (|request|) and a <a>policy</a> (<var ignore>policy</var>):

1. Let |protected resource types| be the result of executing
[[#parse-require-sri-for]] on this <a>directive</a>'s <a for="directive">value</a>.

2. Let |protected| be a <a>boolean</a>, initially set to false.

3. <a for=set>For each</a> |token| of |protected resource types|,
if |request|'s <a for=request>destination</a> is an <a>ASCII case-insensitive match</a> for |token|,
set |protected| to true.

4. If |request|'s <a for=request>url</a>'s <a for=url>scheme</a> is "blob" or "data",
return "Allowed".

5. If |protected| is false,
return "Allowed".

6. Let |parsedMetadata| be the result of <a href="#parse-metadata">parsing</a> |request|'s
<a>integrity metadata</a>.

7. If |request|'s <a for=request>mode</a> is not "no-cors" and
|parsedMetadata| is not the empty <a for=/>set</a>,
return "Allowed".

Note: This logic means that request with matched <a for=request>destination</a> and missing
<a>integrity metadata</a> will be blocked even if it is not currently possible to set its
<a>integrity metadata</a>.
Such requests are originated by, for example, <code>importScripts()</code>,
or `script` elements without crossorigin content attribute.

8. Return "Blocked".

<div class="example">
A page with the following Content Security Policy:

<pre>
Content-Security-Policy: <a>require-sri-for</a> script
</pre>

is equivalent to Content Security Policy delivered through `<meta>`
element:

<pre>
&lt;meta http-equiv="Content-Security-Policy"
content="<a>require-sri-for</a> script"&gt;
</pre>


and requires <a>integrity metadata</a> be present in `script`
elements that contain `src` attribute.
</div>


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

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

Expand Down Expand Up @@ -547,6 +654,17 @@ spec:csp3; type:grammar; text:base64-value
to load the document. A successful load would confirm that the attacker
has correctly guessed the username.


<section>
<h2 id="iana-considerations">IANA Considerations</h2>

The Content Security Policy Directive registry should be updated with the
following directives and references [[!RFC7762]]:

: <a>`require-sri-for`</a>
:: This document (see [[#opt-in-require-sri-for]])
</section>

<!-- ####################################################################### -->

# Acknowledgements # {#acknowledgements}
Expand Down