rrweb icon indicating copy to clipboard operation
rrweb copied to clipboard

Sanitization/Renaming for Security in Snapshot vs Replay reconstruction

Open sdemjanenko opened this issue 1 year ago • 2 comments

I was reviewing the security of the Replayer, specifically the scenario where a bad actor POSTs a fake recording to a recording endpoint. Looking at the logic of the snapshot, i see a lot of code to rename/strip potentially dangerous attributes. An example is

if (isScript) {
  textContent = 'SCRIPT_PLACEHOLDER';
}

I did not observe similar logic in the Replayer to ensure that a script tag isn't inserted (or if it is, that the textContent is SCRIPT_PLACEHOLDER). This means that the fake recording could be constructed to have a script tag with a body of JS that performs some bad activity.

This leads me to a few design questions:

  • why is the code sanitizing on recording versus sanitizing the replayer right before it injects the recorded DOM into the iframe's HTML?
  • what attributes need to be sanitized to protect the html that is inserted (and perhaps there is an opportunity to have a callback fn in the Replayer to mutate a node before insertion).
  • does the CSP of the recorded site need to be stored and then inserted into the iframe? It would be unfortunate if a site went through the pain of setting up a CSP just to have a bypass happen via the Replayer (exfiltrating some sensitive data).

I haven't had the time to write PoCs for any of this yet, but I wanted to open a discussion into organization of the logic of snapshotting + replayer. More logic may need to be moved into the Replayer for security purposes. As a general rule, I think about how the replayer may be able to receive completely untrusted events and insert them "safely" into the DOM.

sdemjanenko avatar Jul 01 '24 17:07 sdemjanenko