freelawproject / recap

This repository is for filing issues on any RECAP-related effort.
https://free.law/recap/
12 stars 4 forks source link

Blindly listening to window.postMessage may be a security problem #236

Closed mlissner closed 1 year ago

mlissner commented 6 years ago

Right now, the way we download PDFs is we hijack the JavaScript that's run when the user clicks the "View Document" button. Instead of running PACER's usual code, we make it run our code, which does:

window.postMessage({id: this.id}, "*");

That means we're sending a pretty boring message ({id: this.id}) to any window that's listening. Fine — those windows can have the message if they want it.

However, we also have a listener that we establish like so:

window.addEventListener(
    'message', this.onDocumentViewSubmit.bind(this), false);

Where we get into trouble is that the onDocumentViewSubmit function is listening to any message, and who knows what message it may get. When it receives a message, it looks up the element with the id described in the message, assumes it's a <form> element, then...submits it as an XHR.

Where does this get an attacker? I'm not sure, but it seems like trouble, and I think I could see an attacker using our extension to make ajax requests via the postMessage function. (They'd also have to tweak the dom a bit to make it so that the parsers in onDocumentViewSubmit wouldn't crash before the XHR was run, but that's doable too, I think.)

The solution here is pretty simple, and it follows the recommendation in Mozilla's docs: In onDocumentViewSubmit, we should check the origin making the request by using:

event.origin

If it's a PACER URL, I think we're fine. If not...that'd be weird, and bad and we should ignore it.

I'd love it if somebody could prove this was a real problem. I intend to implement this fix regardless, but I'll push the priority if it's exploitable.

mlissner commented 6 years ago

Also I should be clear: I'm posting publicly because I don't think this is a real issue, but I want others to prove me wrong. I'll have a fix out regardless, very soon.

mlissner commented 1 year ago

This looks like it might have been fixed in https://github.com/freelawproject/recap-chrome/commit/d5595a4c9800eb0b41518edb2d664b872a8b1e5b, or that maybe that code was never merged. We should sort this out and either close this issue or merge the code (if it's good).