Amphtml: Don't forbid nonces in AMP spec

Created on 11 Jan 2017 · 17Comments · Source: ampproject/amphtml

Nonces are currently forbidden in the AMP spec.

AMP requires that their own content security policy does not produce any errors with AMP pages that others produce (https://www.ampproject.org/docs/reference/spec#security), while simultaneously making the advice given by Google towards best practices for the future of CSP (https://research.google.com/pubs/pub45542.html) incompatible with the specification.

Searching through previous issues, there has been some address to the reasoning for this (https://github.com/ampproject/amphtml/issues/323#issuecomment-147589460):

We cannot use nonces in AMP because they are not compatible with cache-control: public (besides not being supported in Safari).

Safari now supports nonces (so does Microsoft Edge). Additionally, servers that cache content could implement stripping of nonces/forgo sending a CSP header containing a nonce (which would then transfer the scripting risk to their domain).

It should be up to the original website to decide whether setting cache-control: public (and forgoing nonces) is a worthwhile tradeoff. (As far as I know, most AMP pages are served through Google's cache anyway – so the original site's cache-control usually won't matter).

DiscussioQuestion caching

Source

aidantwoods

Most helpful comment

The nonce attribute is now supported on <script> and <style> tags, but will take a few weeks until it's released. We will update the issue again at that time.

Oops, @honeybadgerdontcare already updated this thread.

Gregable on 23 Jan 2017

👍2

All 17 comments

/to @cramforce

jridgewell on 11 Jan 2017

Generally I agree, we could allow nonces if they got stripped by the AMP Caches.

From a security perspective, though, using a CSP more similar to the AMP Cache itself might be appropriate: https://github.com/ampproject/amphtml/blob/master/examples/csp.amp.html#L9

AMP is a bit of a special case with respect to whitelist based CSPs, because it can be so strong, that many (all known) whitelist based circumvention techniques do not apply.

cramforce on 11 Jan 2017

@cramforce Not a lot of sites take advantage of the fact that CSP can be deployed per page (and may require architectural changes). Most apply a single policy domain wide – so I'm not sure that using that CSP is going to be a solution for all (or many) sites (despite that CSP being quite strong).

What you'll probably more likely see is the domains required for AMP being appended to the site's existing CSP (which may contain other sources). Sites have the option to use nonces + 'strict-dynamic' to disable the whitelist, but they can't do this with the current AMP spec (unless they're able to deploy different policies per-page).

aidantwoods on 11 Jan 2017

Is there anything else to do here beside:

Make nonce attribute legal
Remove nonce attribute in cache layer (would be optional, I assume, without CSP rule matching nonce on the cache).

CC @Gregable

cramforce on 11 Jan 2017

I think that would be it! 😃

Stripping the nonce from HTML would only really serve to save bandwidth (so would be optional for usability) – it'll be the CSP on the caching server that will determine whether the browser enforces them.

aidantwoods on 11 Jan 2017

Just to check:

We want to basically allow any number of <script nonce='whatever'></script> tags, only in the <head>, right? Or are there other tweaks to this. I'm not familiar with nonces.

Gregable on 11 Jan 2017

@Gregable It can also go on <style> tags at least. We may just globally whitelist it.

However, this doesn't change any other rules, just makes the nonce attribute legal.

cramforce on 11 Jan 2017

We can globally whitelist it. Still need to do something specific for the script case as <script></script> is not currently legal, so globally whitelisting nonce will not make <script nonce='whatever'></script> legal either, but that's easy to do. Just trying to understand the set of tags you want this for.

Gregable on 11 Jan 2017

Basically this should do this.

<script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>

is legal

<script nonce=mysecret async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>

should be legal.

@sirdarckcat How do you feel about this?

cramforce on 11 Jan 2017

@cramforce (just to pick up on the discussion here)

That seems sensible. Change would only to be to allow the nonce attribute in scripts and styles – arbitrary scripts should stay illegal per spec.

i.e. <script nonce='whatever'></script> is still not allowed.

But currently allowed scripts should permit use of the nonce attribute.

aidantwoods on 17 Jan 2017

I'll take this on for validator and AMP Cache.

@dknecht FYI

honeybadgerdontcare on 19 Jan 2017

👍2

This is now on github, but not in PROD yet. For AMP Cache we strip nonce attributes everywhere.

honeybadgerdontcare on 21 Jan 2017

👍2

Sorry, just noticed this thread.

To answer @cramforce - adding a nonce attribute to the whitelist is fine. That said, since AMP docs are so heavily cached, CSP nonces as defense in depth are quite useless :-). The current whitelist approach is safer.

Mixing both (nonces and whitelists) would be fine, but seems like an overkill and wouldn't provide any real security value.

sirdarckcat on 21 Jan 2017

@aidantwoods - I guess people can hack something up with filters like what was done with nginx or modsecurity, but domain-wide policies in the traditional form are incompatible with nonces (because well, the policy is different for every response).

That said, I get that your goal is to allow a site to use CSP nonces without much effort, and I think that's fair, and I agree it doesn't make much sense adding AMP's whitelist if someone doesn't need it.

sirdarckcat on 21 Jan 2017

Oh hey there again @sirdarckcat, small world ;-)

(because well, the policy is different for every response)

Yup, there is that. Still, adding the nonce in late can be pretty easy to get set up.

Mainly this issue was to make use of 'strict-dynamic' at least compatible with AMP (which is likely a better approach for most sites to adopt – unless they're going to vet their whitelist properly).

That said, since AMP docs are so heavily cached, CSP nonces as defense in depth are quite useless :-)

I'd agree with this with respect to the caching servers, but disagree with regard to the actual content source. As said, in practice, many sites tend not to be very good at putting together whitelists – even though a well thought out one can be safer than a nonce ¯\_(ツ)_/¯

That said, I get that your goal is to allow a site to use CSP nonces without much effort, and I think that's fair, and I agree it doesn't make much sense adding AMP's whitelist if someone doesn't need it

Making CSP (or parts of it) easier to adopt is always a plus 😜

aidantwoods on 21 Jan 2017

The nonce attribute is now supported on <script> and <style> tags, but will take a few weeks until it's released. We will update the issue again at that time.

Oops, @honeybadgerdontcare already updated this thread.

Gregable on 23 Jan 2017

👍2

@honeybadgerdontcare @Gregable @devinlundberg reading this thread, it sounds like we are allowed to use strict-dynamic + nonce attribute? it will work locally b/c of nonce and it will work fine in the cache even though nonce is stripped b/c it's same domain?