1804210 - Styles elements created inside iframes lose their nonce when added to a same-origin parent document and get blocked by CSP

Status: NEW

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

Description

[gset]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

Document has the following CSP configuration.

  content="default-src 'self';
  style-src 'nonce-SUPERSECRETNONCE' 'self';

Our script creates and loads an iframe, and inside it dynamic style elements with correct nonce are created.

Actual results:

Even though the style elements have a correct style.nonce set, attaching them to the top document produces 'Content Security Policy: The page's settings blocked the loading of a resource at inline ("style-src").'

Expected results:

Styles with correct nonce should not be blocked by inline ("style-src") Content Security Policy.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[gset]

Here is a page with a minimal reproducible example:
http://www.usersnapdemo.com/akna/csp-styles/

Comment 3

[Daniel Veditz [:dveditz]]

Confirming.

If you load the frame by itself—which has the same CSP—adding the node to the document works fine with the nonce specified as a DOM property rather than a parsed attribute. The nonce property is being stripped when the node is moved to the parent document.

Of course they're different documents and might have had different nonces (should have, IRL). If we're enforcing nonces on script-added style tags we want to make sure we're checking the right nonce.

From a quick scan the only place I see removing the nonce is
https://searchfox.org/mozilla-central/rev/ef0aa879e94534ffd067a3748d034540a9fc10b0/dom/html/nsGenericHTMLElement.cpp#762-774
( SVG equivalent https://searchfox.org/mozilla-central/rev/ef0aa879e94534ffd067a3748d034540a9fc10b0/dom/svg/SVGElement.cpp#344-356 )

Added in bug 1374612 which wanted to hide the nonce from the DOM. That code is hiding the nonce Attribute, though, not the DOM property, and I can confirm that happens if you set the attribute rather than the DOM property. Concerned about the HasCSPDeliveredThroughHeader check which is used in BindToTree. It makes some sense to worry more about a header policy given that a <meta> CSP could just be read from the document. That's if you have script capability, though, and the bug 1374612 mitigation was aimed at non-scripted CSS attribute games. We certainly don't want to copy that internal flag value between documents though. the other document—even if same origin—might not have a header CSP or might have a completely different nonce even if it does. Also a document can have multiple CSP and might or might not use a nonce in the header CSP specifically.

Chrome behaves as the reporter expects.

Comment 4

[Daniel Veditz [:dveditz]]

Attachment: Self-contained testcase

Here's a testcase that builds on the reporter's, showing 3 different ways to set style on the parent window. This bug is about the 2nd set of cases, where the exact same operation that works in the frame fails when the frame document tries to do it on the parent. Note that since the frame is using srcdoc it inherits the CSP from the parent and thus also requires the nonce to insert inline style.

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

Tom, CSP is mostly your area these days - can you take a look?

Comment 6

[Daniel Veditz [:dveditz]]

Attachment: improved self-contained testcase

Expanded the testcase with a "2a" variant showing that creating the style node directly in the parent works fine as expected. The process of transfering the node from the frame document to the parent causes the nonce property to get stripped.

Given the number of workarounds, especially 2a which would not be much work to fix affected code, this should be relatively low priority.

Comment 7

[Tom Schuster]

When I saw the code in nsGenericHTMLElement::CopyInnerTo I kind of assumed that we need to do some kind of special handling of the nonce when cloning.

When inserting nodes from another document these need to be adopted. In Document::AdoptNode before calling adoptedNode->Adopt, adoptedNode still has the nonce property, but after it seems to have disappeared.

So I suspect we might have to do something similar to CopyInnerTo?

Comment 8

[Daniel Veditz [:dveditz]]

I don't think this is high priority... it's kind of an odd edge case and it does have a workaround.

Comment 9

[Daniel Veditz [:dveditz]]

gset: I think you're going to have to use one of the other methods that works (e.g. example "2a.", or create it entirely through script). We're unlikely to get to this any time soon.