4 ms·

That answer goes on to say, "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

That answer goes on to say, "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.

seethishat 2y ago
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.
- megadal 2y ago
  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.
  - amluto 2y ago
    > 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.
    - deleted 2y ago
      [deleted]
    - megadal 2y ago
      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.
      - kevin_thibedeau 2y ago
        PDF forms don't require JS.
        megadal 2y ago
        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.
        amluto 2y ago
        > 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?
masklinn 2y ago
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.
- gruez 2y ago
  >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.
- tgsovlerkhgsel 2y ago
  > I'd just disable script evaluation if you don't specifically need that. This vuln works even with scripting in PDF.js disabled.

seethishat 2y ago

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.

megadal 2y ago
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.
- amluto 2y ago
  > 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.
  - deleted 2y ago
    [deleted]
  - megadal 2y ago
    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.
    - kevin_thibedeau 2y ago
      PDF forms don't require JS.
      - megadal 2y ago
        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.
        amluto 2y ago
        > 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?

masklinn 2y ago

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.

gruez 2y ago
>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.
tgsovlerkhgsel 2y ago
> I'd just disable script evaluation if you don't specifically need that. This vuln works even with scripting in PDF.js disabled.