Regression: support for strict CSP broken by style mutation

[razor-x]

The optimization in PR #464 broke support for users who run a strict Content-Security-Policy (CSP).

Specifically, this line sets the style attribute on a DOM node and will be blocked without style-src: 'unsafe-inline' (which is the unsafe CSP).

rrweb/packages/rrweb/src/record/mutation.ts

Line 487 in 661c746

old.setAttribute('style', m.oldValue);

For any apps that pull in the affected versions and have a strict CSP, this issue will generate a very large numbers of errors like the one below (one for each time that line of code runs). As a possible side effect, any error reporting services or report-url endpoints may be quickly overwhelmed with error reports.

[razor-x]

@eoghanmurray The tech for this project is a bit beyond my area of knowledge, but since you are the original owner of the PR, I was wondering if you have any thoughts on workarounds. Would it be possible to implement this using a data attribute like data-style instead of style on the app you are recording? I don't think CSP will care about data attributes.

[Juice10]

@razor-x would you mind if we stripped all the CSP policies on replay? I think that would solve this issue for you.

[razor-x]

@razor-x would you mind if we stripped all the CSP policies on replay? I think that would solve this issue for you.

I'm not sure I understand this proposal. Can you point at an example?

To further clarify, this is an issue when the DOM is being recorded not replayed. As I understand things, as long as there is JS code that tries to write style attributes it will conflict with a strict CSP.

[razor-x]

This is what I am thinking might work, just read and write to a different attribute. Not sure what other spots if any would need an update, I tired to use the other PR to see what might need to change: rxfork@1d6d8a1

(I'd take this further, but I tried for a bit to get the tests passing on my local but hit various errors and had to give up.)

[eoghanmurray]

Thanks for alerting me on this!
The data-style solution wouldn't work as the style attribute is special and has an API associated with it (old.style.getPropertyValue).
The this.doc.createElement('span') bit is just to create a dummy element so we can access this API (the style attribute comes into the mutation as text information).
We'll need to come up with something better than this.doc.createElement (this did bother me at the time, as this is in the recording!)

• Unfortunately you can't instantiate a CSSStyleDeclaration directly
• CSSStyleValue.parse() isn't widely supported (and not clear whether it would help)

I wonder do we need to go so far as creating an iframe object (could that have a different CSP policy) and executing createElement within that? Would that be something you could check? Or let me know how to create a document with this type of restrictive CSP policy.

[eoghanmurray]

@razor-x would you mind if we stripped all the CSP policies on replay? I think that would solve this issue for you.

@Juice10 This is on the record side; we are creating and discarding an anonymous here just to access it's style attribute.

[eoghanmurray]

@razor-x how does the document itself modify the style in the first place? (the original modification that generated the mutation)
Could you have a look at the calling code for that and check how it's actually doing it?

(via dev tools > inspector > (the element) > break on attribute modifications)

[razor-x]

@razor-x how does the document itself modify the style in the first place? (the original modification that generated the mutation) Could you have a look at the calling code for that and check how it's actually doing it?

(via dev tools > inspector > (the element) > break on attribute modifications)

Sure. Just some more context on how I discovered the issue. I recently updated our app to MUI v5 which is supposed to have strict CSP compatibility now (since they switched to emotion / styled-components and no longer use CSS in JS). I enabled the strict CSP headers and tested the site in staging where we are NOT running rrweb and saw no errors. When moved to prod where recording is enabled, I saw the CSP errors triggered by the referenced mutation line from rrweb.

I actually would expect the app's attribute updates to trigger CSP but there must be a reason they are allowed.

Here is one of the things triggering a modification that gets picked up by the rrweb mutation.

[razor-x]

I loaded it up in dev mode and grabbed the non-minified react code that it breaks on.

[eoghanmurray]

node.style.transition = theme.transitions.create('opacity', transitionProps);

Ok so maybe it's okay to access the style property but not set the attribute?

(I'm ignoring the second screenshot as the attribute being set there is aria-owns and not style)

In terms of speculative investigation, could you check whether something like the following is permissable in your CSP context (you can paste it in in the console and see what errors arise):

var throwaway = document.createElement('iframe');
throwaway.setAttribute('sandbox', 'allow-same-origin allow-scripts');  // if it works, I'd also want to know if it works without this!
var sp = throwaway.contentDocument.createElement('span');
sp.setAttribute('style', 'background:black;');

[razor-x]

As a sanity check I deployed the restrictive CSP back to my testing environment and confirmed the (non-rrweb) updates do not trigger violations in chrome or firefox. I also ran your scripts against that.

(I'm ignoring the second screenshot as the attribute being set there is aria-owns and not style)

Ah good catch, I played to the other breaks, hopefully this is move useful. I think the first one it the style that makes the box appear and the second is the box being hidden.

In terms of speculative investigation, could you check whether something like the following is permissable in your CSP context (you can paste it in in the console and see what errors arise):

var throwaway = document.createElement('iframe');
throwaway.setAttribute('sandbox', 'allow-same-origin allow-scripts');  // if it works, I'd also want to know if it works without this!
var sp = throwaway.contentDocument.createElement('span');
sp.setAttribute('style', 'background:black;');

There maybe an issue with these, I got non-CSP errors in all cases.

chrome

firefox

Then as a control I tried this on https://example.com/

[razor-x]

I modified the script and tried again

var throwaway = document.createElement('iframe');
throwaway.setAttribute('sandbox', 'allow-same-origin allow-scripts');  // if it works, I'd also want to know if it works without this!
document.body.appendChild(throwaway);
var sp = throwaway.contentDocument.createElement('span');
sp.setAttribute('style', 'background:black;');

example.com

With strict CSP

[razor-x]

I did some digging and I suspect the key may be that style updates using the CSSOM by an already-allowed CSP script are allowed without unsafe-inline.

Here's what's I found that seems to suggest this:

• Change transitions to not require style-src 'unsafe-inline' CSP. sveltejs/svelte#6662 (comment)
• fix CSP by injecting styles using CSSOM chartjs/Chart.js#5952
• Use CSSOM for style manipulations Addepar/ember-table#566
• https://lists.w3.org/Archives/Public/public-webappsec/2013Jul/0006.html

[eoghanmurray]

right, contentDocument isn't available until the iframe is appended to the page; I thought I got the opposite result while testing but must have accidentally added my variable to the page or reused one or something.

Could you try simpler:

var throwaway = new Document();
var sp = throwaway.createElement('span');
sp.setAttribute('style', 'background:black;');

I imagine the CSP is inherited by the document, but maybe not given the new document isn't actually attached to anything?

[eoghanmurray]

(I'd use the CSSOM, but the old style attribute is provided as a string, and we'd have to loop through it to parse it, which I'm not confident we'd get right for whatever edge cases - setting the attribute lets the css engine do this work!)