rrweb
rrweb copied to clipboard
Sanitization/Renaming for Security in Snapshot vs Replay reconstruction
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.