1374612 - CSP: Hide nonce values from the DOM

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P1)

Description

[Christoph Kerschbaumer [:ckerschb]]

Prevent nonce exfiltration via CSS selectors and similar tricks. By hiding the nonce from the DOM those kind of CSP policy bypasses can be prevented.

See also:
https://github.com/whatwg/html/pull/2373
https://github.com/w3c/web-platform-tests/tree/master/content-security-policy/nonce-hiding

Comment 1

[robclap8]

Hi,

The change described in the original report (hiding nonces attribute values) has been merged on Nov 22, 2017 but this does not seem to be addressed yet.

Are there any plans to do so? :)

Comment 2

[Lukas Weichselbaum]

We briefly discussed this at TPAC. Do you may have an ETA for this? :)

Comment 4

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1374612 - CSP: Hide nonce values from the DOM. r=smaug

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/59fe98b41d80
CSP: Hide nonce values from the DOM. r=smaug

Comment 7

[Dorel Luca [:dluca]]

Backed out changeset 59fe98b41d80 (bug 1374612) for WPT failures in /html/dom/idlharness.https.html. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290745033&repo=autoland&lineNumber=3863

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=59fe98b41d80de9d6b56221cba7e1f814f6720a3

Backout:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290745033&repo=autoland&lineNumber=3863

Comment 8

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62f803edfb19
Backed out changeset 59fe98b41d80 for WPT failures in /html/dom/idlharness.https.html. CLOSED TREE

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Pulsebot from comment #8)

Backout by [e-mail]:

Thanks - I am on it!

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ec4c2b2a561b
CSP: Hide nonce values from the DOM. r=smaug

Comment 11

[Stefan Hindli [:stefan_hindli]]

Backed out changeset ec4c2b2a561b (Bug 1374612) for causing wpt permafails in /html/dom/reflection-metadata.html CLOSED TREE

https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&fromchange=1d55103f9020fa24e38c083bc2cb0c8ab3a165a9&selectedJob=290819404

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290819404&repo=autoland&lineNumber=26242

Comment 12

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/eb328df4c35f
Backed out changeset ec4c2b2a561b for causing wpt permafails in /html/dom/reflection-metadata.html CLOSED TREE

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Pulsebot from comment #12)

Backout by [e-mail]:

Rrrrrh - again? On it ...

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/190ac0f2afb3
CSP: Hide nonce values from the DOM. r=smaug,annevk

Comment 15

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/190ac0f2afb3

Comment 16

[nightpool]

Note that the intersection of this bug and https://bugzilla.mozilla.org/show_bug.cgi?id=1446231 might lead to a compatibility issue for Web Extensions. We got a report from a user that our Web Extension was broken on Firefox Beta, and it turned out to be due to this change—we were only using getAttribute to propogate nonce values. While Chrome has implemented nonce-hiding for a while, it also implemented a more general CSP bypass for script nodes injected by extensions, so we only ever implemented the getAttribute route and were broken by this change. Is there a way for Firefox to lessen this breakage (in my opinion, the ideal way is to implement 1446231), or at the very least, can this rate a mention in the WebExtension or Security changelogs?

Also, smaller thing, but it looks like https://github.com/mdn/browser-compat-data/blob/master/api/HTMLElement.json wasn't updated for this change, so it still shows the .nonce API as unsupported on Firefox. I don't know the process by which this gets updated, but it seems like that should happen here?

Comment 17

[Christoph Kerschbaumer [:ckerschb]]

(In reply to nightpool from comment #16)

Note that the intersection of this bug and https://bugzilla.mozilla.org/show_bug.cgi?id=1446231 might lead to a compatibility issue for Web Extensions. We got a report from a user that our Web Extension was broken on Firefox Beta, and it turned out to be due to this change—we were only using getAttribute to propogate nonce values. While Chrome has implemented nonce-hiding for a while, it also implemented a more general CSP bypass for script nodes injected by extensions, so we only ever implemented the getAttribute route and were broken by this change. Is there a way for Firefox to lessen this breakage (in my opinion, the ideal way is to implement 1446231), or at the very least, can this rate a mention in the WebExtension or Security changelogs?

Anne, Smaug, Kris, what's your take? With our current way of implementing the nonce hiding, I don't think adding carve-outs is easily doable. Any thoughts?

Comment 18

[Frederik Braun [:freddy]]

nightpool, did you try setting 'strict-dynamic' in your web extensions' CSP in Firefox? I think that should give you nonce propagation implicitly.

Comment 19

[Lukas Weichselbaum]

In our experience it's best to fix your Extension code (esp. if it was already working without any extra carve-outs in FF).
We usually recommend to retrieve CSP nonces in the following way which works in all browsers regardless if they're "nonce-hiding" or not:

var nonce = script['nonce'] || script.getAttribute('nonce');

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

(In reply to nightpool from comment #16)

Also, smaller thing, but it looks like https://github.com/mdn/browser-compat-data/blob/master/api/HTMLElement.json wasn't updated for this change, so it still shows the .nonce API as unsupported on Firefox. I don't know the process by which this gets updated, but it seems like that should happen here?

That kind of update doesn't happen in bugs implementing features. (But I don't know how it happens)

Comment 21

[nightpool]

(In reply to Frederik Braun [:freddy] from comment #18)

nightpool, did you try setting 'strict-dynamic' in your web extensions' CSP in Firefox? I think that should give you nonce propagation implicitly.

The problem is not my web extension's CSP, it's the CSP of the page that hosts the content script, which we can't control. To inject any other script nodes onto the page, we have to retrieve the nonce from a script on the page and then add it to the script we're injecting. So we were doing something like const nonce = document.querySelector("[nonce]").find(script => script.getAttribute("nonce")), and then adding that to the inline scripts we injected onto the page.

(In reply to Lukas Weichselbaum from comment #19)

In our experience it's best to fix your Extension code (esp. if it was already working without any extra carve-outs in FF).
We usually recommend to retrieve CSP nonces in the following way which works in all browsers regardless if they're "nonce-hiding" or not:

var nonce = script['nonce'] || script.getAttribute('nonce');

Yes, we implemented this as a workaround, but because the page's CSP only affects content scripts in Firefox, my guess is that there are lots of content scripts out there that don't have this code in them already. Like I said, ultimately I think the underlying bug here is that Firefox subjects script nodes inserted by content scripts to the same CSP as they're inserted on, which is both a worse experience for developers and different from how Chrome does it.

Ultimately, I don't have any way to quantify this breakage, and it seems like we're too late in the cycle to get https://bugzilla.mozilla.org/show_bug.cgi?id=1446231 implemented for Firefox 75, but it feels like at least a release note or something is warranted.

Comment 22

[Anne (:annevk)]

Update to MDN is tracked by the dev-doc-needed keyword. Adding this to release notes seems reasonable, but I don't think we should provide a special extensions code path for this given they can use the IDL attribute.

Comment 23

[Florian Scholz (Open Web Docs)]

(In reply to Olli Pettay [:smaug] from comment #20)

(In reply to nightpool from comment #16)

Also, smaller thing, but it looks like https://github.com/mdn/browser-compat-data/blob/master/api/HTMLElement.json wasn't updated for this change, so it still shows the .nonce API as unsupported on Firefox. I don't know the process by which this gets updated, but it seems like that should happen here?

That kind of update doesn't happen in bugs implementing features. (But I don't know how it happens)

I've created https://github.com/mdn/browser-compat-data/pull/5888 for this.

Also now announced on Firefox 75 for developers:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75#Security

And documented in the reference:
https://developer.mozilla.org/en-US/docs/Web/API/HTMLOrForeignElement/nonce

Who can review this?

Comment 24

[Anne (:annevk)]

Looks mostly accurate. I updated https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75 as we already supported the nonce attribute. It mainly applies to more elements now and the content attribute is hidden from script (the IDL attribute isn't, perhaps obviously).

Florian, I think per nightpool's request we should also add a note to "Changes for add-on developers" in that nonce hiding might affect them and that any .getAttribute("nonce") call they have probably needs to become a .nonce get.

Comment 25

[Florian Scholz (Open Web Docs)]

I updated https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75 as we already supported the nonce attribute. It mainly applies to more elements now and the content attribute is hidden from script (the IDL attribute isn't, perhaps obviously).

Great, thank you! Do you know when .nonce landed initially? I thought this bug implemented it and so this PR https://github.com/mdn/browser-compat-data/pull/5888 sets the compat data for it to Firefox 75, but if it in fact was available earlier, I'd like to know when.

Florian, I think per nightpool's request we should also add a note to "Changes for add-on developers" in that nonce hiding might affect them and that any .getAttribute("nonce") call they have probably needs to become a .nonce get.

I've added it to the add-ons section as well.

Comment 26

[Florian Scholz (Open Web Docs)]

(In reply to Florian Scholz [:fscholz] (MDN) from comment #25)

Great, thank you! Do you know when .nonce landed initially? I thought this bug implemented it and so this PR https://github.com/mdn/browser-compat-data/pull/5888 sets the compat data for it to Firefox 75, but if it in fact was available earlier, I'd like to know when.

This was clarified. Initial .nonce support happened in this bug as .nonce didn't land earlier in bug 1389421 (was backed out).

I've mentioned this now twice on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/75
(in the security section and in the section for add-on devs)

Reference page updates on https://developer.mozilla.org/en-US/docs/Web/API/HTMLOrForeignElement/nonce and now also on https://developer.mozilla.org/en-US/docs/Web/API/Element/getAttribute to refer to use .nonce instead .getAttribute("nonce")

Compat table will be updated later this week when https://github.com/mdn/browser-compat-data/pull/5888 makes it to MDN prod.

Calling this complete for now. Please let me know if there is anything else here in terms of docs.

Comment 27

[Kris Maglione [:kmag]]

I think you want bug 1446231.