7 ms·

Accepted answer: "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 sec

Accepted answer: "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.

baobabKoodaa 2y ago
What is wrong with that accepted answer?
- daghamm 2y ago
  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?
  - baobabKoodaa 2y ago
    I think you're being unnecessarily harsh. 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.
    - cxr 2y ago
      > I think you're being unnecessarily harsh. 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.
naberhausj 2y ago
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]
Art9681 2y ago
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.

baobabKoodaa 2y ago

What is wrong with that accepted answer?

daghamm 2y ago
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?
- baobabKoodaa 2y ago
  I think you're being unnecessarily harsh. 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.
  - cxr 2y ago
    > I think you're being unnecessarily harsh. 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.

naberhausj 2y ago

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]

Art9681 2y ago

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.