Found this fun stack overflow post:
https://stackoverflow.com/questions/49299000/what-are-the-se...
https://stackoverflow.com/questions/49299000/what-are-the-se...
"Potentially, there is a tiny possibility... Keep in mind, it's a web application, and worse it can do is XSS attack"
One sad thing about security is that everyone and their uncle is a security expert.
People who have been in this game more than six months would never making such a claim.
And only XSS? What does that mean in the context of the page, or an electron app? How can this guy know "just an XSS" is not catastrophic?
First off, are we not supposed to have "random guys" writing stuff on Stack Overflow and Wikipedia? Because that's kind of how those websites work: they rely on "random guys" to do all of the writing, rather than relying on credentialed experts only. I sure think Stack Overflow and Wikipedia are very useful resources despite having "random guys" do all the writing.
Secondly, you attack the random guy for... correctly identifying that "the worst it can do is an XSS attack". This is very useful and accurate information. Information like this is typically absent from all kinds of vulnerability disclosures. When you read on the news that something something has a vulnerability, they typically they don't give you the practically useful bit of information, like what is the practical scope. Is it a 0-click RCE or is it a XSS inside a web app? They don't tell you. Except this random guy, who accurately identifies this information.
> How can this guy know "just an XSS" is not catastrophic?
"Just an XSS" is the correct description of the severity here.
More like dogpiling and coattail-riding of the current in-focus topic. Both comments smack of smug know-betterness but are accompanied only by vague remarks and no real claims that might be subjected to scrutiny. It's almost like dogwhistling for karma.
"If you serve untrusted PDFs in a PDF viewer and you are hosting at your location, it is better be located at different origin than your main app, www.example.org vs pdfviewer.example.org."
My understanding is that this CVE is an XSS attack, so isn't this advice sound? The RCE portion of this CVE is for Election, where every XSS attack is twice as fun.
Is there something about his answer that is wrong that I don't see? I hardly think we can fault someone simply for having faith in the integrity of software that everyone else trusted until now.
Is the origin right? Are all the security headers correctly set? Is it even possible to keep up with all the stuff that is published, today, to sort of try and secure a web app? I don't think so.
My approach is... no JavaScript (script-src 'none'). Just don't do it.
You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
That's like saying your approach to web application hardening is to disable all inbound connections. You quite necessarily need those for a web application.
I can't see how this would be pragmatic or productive, or maybe it's not meant to be.
Most of the time, you get better results by just serving up the PDF as Content-Disposition: inline. 90% of JavaScript PDF viewers are crap (although PDF.js is decent), but the browser on all dignified platforms still does better than any fancy JavaScript I’ve ever seen. Loads faster, too.
I don't think anyone but a bored hobbyist is implementing or using a JS PDF renderer solely for rendering and the people who are using it for the aforementioned reasons don't care about load times, the document has to be processed somehow by the user agent.
The suggestion that JS is optional here is nonsense and that the built in browser PDF renderer (written in a lower level language than JS) is faster is common knowledge.
Again, I don't see how this suggestion is pragmatic or productive, but still, maybe we're not trying to be here.
You also can prepopulate the form with user input from previous webpages/the user account. This is how a lot of HRISes do it.
Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
And this conversation is still far away from the point: you need JS for a JS based PDF renderer, and there are valid uses cases where one is required.
> Usually people want onboarding to be as frictionless as possible. Downloading the PDF and using some editor outside the website then coming back to upload it counts as friction.
Wait, are you saying there's a workflow for which the most frictionless solution is to have the user fill out a PDF, on an authenticated website and submit the PDF in the browser? As opposed to, say, <form>? Can you elaborate?
It would have worked much better as an emailed PDF, or a simpler form. Or an ordinary non-PDF form that would generate a filled-in PDF that the user could then sign.
> I'm going to discontinue this conversation though.
Oh, well.
I'm sure a lot of people here will disagree but most websites don't target the minority that prefers an email based workflow.
I tend to agree outside the context of a browser, but the post is about PDF.js.
> fill forms in the browser (where their authenticated context resides)
I have never, in my entire life, seen a web form implemented as a PDF where this was anything other than miserable. Use a form, thank you very much. The less SPA magic and the fewer intermediate submit buttons, the better. (Maybe, if the actual goal is for a user to fill out a form and print the result, offer PDF.js to users on Windows who might otherwise be stuck with Acrobat. I distinctly remember Acrobat being the best PDF-form-filling software maybe 20 years ago, but Acrobat has gotten, if anything, worse, and basically every other package out there runs circles around it.)
Frankly I'd just disable script evaluation if you don't specifically need that.
And how do you know whether you "specifically need that"? As the answer says, it's not for scripting within the pdf itself, it's for optimizing font rendering. For pdfs that you don't control, it's basically impossible to know whether that'd be needed or not. Even for pdfs that you do control, in a large company it's very likely that the team that's configuring pdf.js isn't talking to the team that generates the pdfs, which means you have a similar problem.
This vuln works even with scripting in PDF.js disabled.
Not only does it correctly identify the attack vector of this CVE, but I think his advice on how to mitigate it is sound. Is there something I'm missing? The only flaw I see is that it doesn't consider the implications of using PDF.js in Electron.
The option isn't supposed to allow XSS-by-design (which the original requester was worried about), the possibility of a vulnerability is mentioned, the impact of a vulnerability is correctly described (XSS not RCE or similar), and mitigations that would effectively limit the impact of such a vulnerability are presented (separate origin).