4 ms·

If you have an issue with human error and don't design your programmed tool to avoid letting the errors out into the world, then it is the fault of the tool.

bastawhiz 9y ago
I'm not sure what the argument you're putting forth is. All of the HTML-generating tools I'm aware of (barring dumb string templating tools) work sufficiently well and prevent human error. My point is that there's nothing wrong with HTML. HTML isn't a tool, it's a format for storing and transmitting hypertext. If you're using React or HAML or any of the other HTML-generating tools, you're effectively immune from XSS. I'm putting forth that developers aren't using effective tools (shame on every templating engine that doesn't escape by default), and that calling the web as a platform bad is a bit nonsensical. It's like saying "folks are writing asm by hand and their code has security issues, therefore x86_64 is insecure".
- quadrangle 9y ago
  Well put. I agree with all of that essentially.
- mike_hearn 9y ago
  The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond what any tool is capable of stopping. Look at one of the XSS holes found by Homakov that I linked to from my article: http://sakurity.com/blog/2015/06/25/puzzle2.html http://sakurity.com/blog/2015/06/25/puzzle2.html The XSS occurs on this line of JavaScript, not HTML: $.get(location.pathname+'?something') That's a simple line of JQuery that does an XmlHttpRequest to the same page that was loaded with an additional parameter. By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless. Show me the tool that would have avoided that type of exploit, without already knowing about it and having some incredibly specific hardcoded static analysis rule. When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. To paraphrase Veekun, scratch the surface of web security and you'll find yourself in a bottomless downward spiral, uncovering more and more horrifying trivia.
  - homakov 9y ago
    Thanks for a mention. Yes, I find web deeply broken. If any big company decides to reengineer it from scratch: I'm available to help for free :)
  - bastawhiz 9y ago
    > If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. I think you're missing another two obvious explanations: 1. Lack of education when picking a tool (copy paste from bad SO answers is a frequent source of bad code). 2. Developers don't care. If it works, why bother wrapping your head the rest of the way around to understand why it works or whether it's secure? > By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless. Sure, ERB before RoR essentially had security turned off by default (as I noted). And this issue could happen with any other non-web system, turning into any other kind of vulnerability. This isn't a web problem, it's a system security problem. Bad inputs in a "native" app could lead to security issues in the output of apps on other devices. Badly implemented binary data decoders in a desktop application could do far worse than a XSS in the browser. This problem is misattributed as a "web problem" because there are far more complete systems on the web than there are on nearly any other platform. It's like the tired argument that Mac is more secure than Windows, but Windows has historically had an overwhelmingly outsized market share, making OS X issues far less valuable to attackers. > When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. I don't disagree that these issues are common, but I disagree that the web is unsafe by design. The web is a platform. If everyone wrote their Python APIs without a framework, I can guarantee they would be littered with security holes. If everyone wrote their own text renderer in C++, just displaying strings on the screen would be a dangerous task. There are good tools that make it really hard to fuck up on the web. Seriously, try to accidentally have a XSS vulnerability in an isorendered React app with Apollo. The problem is folks that want to jQuery-jockey their way across the finish line and don't understand that they are making terrible mistakes.
    - mike_hearn 9y ago

bastawhiz 9y ago

I'm not sure what the argument you're putting forth is. All of the HTML-generating tools I'm aware of (barring dumb string templating tools) work sufficiently well and prevent human error. My point is that there's nothing wrong with HTML. HTML isn't a tool, it's a format for storing and transmitting hypertext. If you're using React or HAML or any of the other HTML-generating tools, you're effectively immune from XSS. I'm putting forth that developers aren't using effective tools (shame on every templating engine that doesn't escape by default), and that calling the web as a platform bad is a bit nonsensical. It's like saying "folks are writing asm by hand and their code has security issues, therefore x86_64 is insecure".

quadrangle 9y ago
Well put. I agree with all of that essentially.
mike_hearn 9y ago
The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond what any tool is capable of stopping. Look at one of the XSS holes found by Homakov that I linked to from my article: http://sakurity.com/blog/2015/06/25/puzzle2.html http://sakurity.com/blog/2015/06/25/puzzle2.html The XSS occurs on this line of JavaScript, not HTML: $.get(location.pathname+'?something') That's a simple line of JQuery that does an XmlHttpRequest to the same page that was loaded with an additional parameter. By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless. Show me the tool that would have avoided that type of exploit, without already knowing about it and having some incredibly specific hardcoded static analysis rule. When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. To paraphrase Veekun, scratch the surface of web security and you'll find yourself in a bottomless downward spiral, uncovering more and more horrifying trivia.
- homakov 9y ago
  Thanks for a mention. Yes, I find web deeply broken. If any big company decides to reengineer it from scratch: I'm available to help for free :)
- bastawhiz 9y ago
  > If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. I think you're missing another two obvious explanations: 1. Lack of education when picking a tool (copy paste from bad SO answers is a frequent source of bad code). 2. Developers don't care. If it works, why bother wrapping your head the rest of the way around to understand why it works or whether it's secure? > By itself, it is not an XSS. But if the backend is/was running Ruby on Rails (presumably some old version by now) then it could turn into an XSS due to a combination of features that all look superficially harmless. Sure, ERB before RoR essentially had security turned off by default (as I noted). And this issue could happen with any other non-web system, turning into any other kind of vulnerability. This isn't a web problem, it's a system security problem. Bad inputs in a "native" app could lead to security issues in the output of apps on other devices. Badly implemented binary data decoders in a desktop application could do far worse than a XSS in the browser. This problem is misattributed as a "web problem" because there are far more complete systems on the web than there are on nearly any other platform. It's like the tired argument that Mac is more secure than Windows, but Windows has historically had an overwhelmingly outsized market share, making OS X issues far less valuable to attackers. > When I argue that the web is unsafe by design, it's because cases like that aren't rare, they're common. I don't disagree that these issues are common, but I disagree that the web is unsafe by design. The web is a platform. If everyone wrote their Python APIs without a framework, I can guarantee they would be littered with security holes. If everyone wrote their own text renderer in C++, just displaying strings on the screen would be a dangerous task. There are good tools that make it really hard to fuck up on the web. Seriously, try to accidentally have a XSS vulnerability in an isorendered React app with Apollo. The problem is folks that want to jQuery-jockey their way across the finish line and don't understand that they are making terrible mistakes.
  - mike_hearn 9y ago