"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.
Things have gotten so complex that it's difficult to reason about security (even for experts). This is especially true when we're talking about JS code that is running on the client and accepting untrusted input from the global Internet.
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.
Your approach to sandboxing browser PDF rendering is to just not 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.
> You realize this particular problem requires JS to solve, right? It's not just there arbitrarily.
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 mean firefox's built in pdf reader is PDF.js. Also the desktop version of adobe reader used to run javascript embedded in pdfs by default as a "feature". I'm not sure you can get away from it at this point, but it would be nice to have the option to just use a desktop pdf reader that doesn't even support javascript or running any code embedded in the pdf. Maybe my use case is limited but I don't see the point of it. If you want interactivity you can use a website so people can expect that sort of stuff.
People don't usually use PDF.js just to render PDFs. You can also extract text to use within a web application, preview a PDF, have users sign PDFs and fill forms in the browser (where their authenticated context resides) and a host of other things.
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.
From personal experience browsing websites, especially sites that display catalogues, manuals, or specifications, a whole lot of them produce PDF content and then go out of their way to render it with JavaScript. The worst use horribly performing systems that make consuming the content miserable. Better commercial systems are a step up (Issuu is a whole company that seems to be developed around doing this). Even better ones use PDF.js. But the best ones... drumroll please... just link to the PDF as Content-Disposition: inline. If users want to save it, then they click save. And this is great -- you want your users to have the easiest time possible interacting with your marketing material.
> 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.)
They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
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.
> They do if your want to fill them out in the browser coupled with an authenticated context, which is usually pretty important for forms. Usually you don't just want random users filling out any data within your enterprise.
> 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?
I once had the displeasure of submitting a Form W-9 on an authenticated website. It was an unmitigated disaster involving one time codes distributed over email via a team of apparent actual people outsourced outside the US, a website, PDFs POSTed to said website, and marked-up copies of said PDFs emailed back by said outsourced team asking inane questions. And, presumably since the whole mess wasn’t actually machine-readable, the form still got entered wrong and incorrect tax forms were issued.
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.
Sometimes the PDF itself has to be signed. No conversion from forms. Also, tons of people would rather not have to download the PDF and email it, especially if they are on mobile. There's almost 0 usability advantage to doing that, because Adobe acrobat or whatever other pdf reader that users have and lets them sign stuff is often worse than even a JavaScript implementation. I'd much rather just sign on the browser than send an email back and then... wait or not have an immediate confirmation, or just having to deal with anything else than just pressing next.
I'm sure a lot of people here will disagree but most websites don't target the minority that prefers an email based workflow.
Or they could just implement full support for PDF. It had forms from the get go in the 90's. There is zero need to implement the functionality with JS.
The advice is sound... mostly: there are ways to relax the different-origin nature of subdomains so you'd have to ensure that you're not using them, and some web properties have relaxed SOP by default e.g. cookies, renderer processes, ..., the public suffix list exists to try and mitigate these issues.
Frankly I'd just disable script evaluation if you don't specifically need that.
>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.
For one, every security disaster starts with people listening to a random guy claiming that the probability of something being exploitable is virtually zero :)
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.
Another sad thing is that no matter the accolades of the "security expert", the truth is that they havent been "hacked" because they or their business has nothing of value to those skilled enough to take it. "I can" doesn't mean "I want to", or "it's worth our time". Which is to say, everyone is an expert, until they are not.
"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.