Closed mlissner closed 1 year 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.
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).
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:
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:
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 inonDocumentViewSubmit
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: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.