5 ms·

Previously discussed here: https://news.ycombinator.com/item?id=24919710 https://news.ycombinator.com/item?id=24919710 Yes, bobby tables has also been tried.

Previously discussed here: https://news.ycombinator.com/item?id=24919710 https://news.ycombinator.com/item?id=24919710 Yes, bobby tables has also been tried. If I may derail, as not a web expert: XSS bugs me. If I send text to your server, and your idiot server executes it as code, it's a server flaw. If a server sends my browser text, however, and my idiot browser executes it as code, that's also a server flaw. I mostly understand the reason, but... doesn't that just feel wrong?

wccrawford 6y ago
In both cases, the server is the thing that's actually in control. Your browser doesn't know if code is malicious or not and has no choice but to run it as the server says to. The server, on the other hand, does know if some text is potentially malicious and can take steps to prevent it from being malicious. So the server is responsible in both cases because it has all the knowledge necessary. If the browser tried to prevent code execution then no code would execute. It can't know the original origin of the text.
beaconstudios 6y ago
you send the server text; the server sends your browser HTML. That's the difference - the server is taking the text you sent, and allowing it to escape its textual confines and become code/markup. HTML is nice enough to make this easy, where SQL servers have gone the way of parameterized queries to explicitly make this impossible (harder?)
lucideer 6y ago
> If a server sends my browser text, however, and my idiot browser executes it as code, that's also a server flaw. XSS is not the server sending your browser text, that your idiot browser executes as code. XSS is the idiot server sending the browser code that the server thinks is text. The browser's job is to execute code the server sends it: the browser trusts the server, and it's the server's job to ensure what it's sending as code is code and what it's sending as text is text.
- KMag 6y ago
  Since the days of phone phreaking, we've known in-band signalling is just a terrible idea. Any time a legal message token/signal/sequence in your data payload can escape data to metadata/code status, encapsulation complexity goes way up and at least one implementer is going to screw something up in a bad way. XSS was entirely predictable from the design of <script> tags and onload, onclick, etc. handler HTML tag attributes. One alternative would be to force all <script> tags to come immediately after the <html> tag (before any <head>, <body>, <style>, etc. tag), and have it be a fatal error disabling scripting if a script tag came after any other html tag except for <html>. You'd also need to reverse the way onlead, onclick, etc. handlers are set, having them set from the script side instead of setting handlers via html tag attributes. If you were extremely careful about the design, you might be able to have scripts opt-in individual functions to being handlers specified in HTML tag attributes, but the corner cases get hairy very quickly. If you need nice general libraries handling clicks, etc, it's probably best to have your scripts scan for the tags to have handlers attached rather than having the tags decide their own handlers. The are some other solutions involving unambiguous length-prefixed type-tagged sections clearly separating text and code, but those are better suited to non-textual formats, and a weird hybrid text-and-binary format (such as PDF) is another type of security minefield. Edit: formatting. Also, one of my favorite classes was a retrospective look at a variety of computer systems, critiquing very good and very bad design decisions. We looked at X11, zlib, Therac-25, Ariane 5, etc.
  - andrewaylett 6y ago
    A Content Security Policy without 'unsafe-inline' is fairly close to what you describe.
    - lucideer 6y ago
      'unsafe-inline` still allows external scripts, so isn't really effective on it's own, but yeah CSP does generally solve the problem the gp is talking about.
  - lucideer 6y ago
pjc50 6y ago
> If a server sends my browser text, however, and my idiot browser executes it as code That's entirely normal. There's no hard distinction between "text" and "code", and there always end up being leaks in the systems designed to keep them apart. In the case of XSS, the difference is between "text" of the webpage that you're supposed to execute and "text" that was inserted into the web page from somewhere else.
progval 6y ago
Not to me. The browser executes it as code in a sandbox, that is dedicated to that website. No harm was done outside the sandbox (if there was, it would be a client flaw); it's just the server doing bad things in the sandbox the client "allocated" to it.
BerislavLopac 6y ago
> If a server sends my browser text, however, and my idiot browser executes it as code This is literally the whole idea of how browsers are supposed to work...

wccrawford 6y ago

In both cases, the server is the thing that's actually in control. Your browser doesn't know if code is malicious or not and has no choice but to run it as the server says to. The server, on the other hand, does know if some text is potentially malicious and can take steps to prevent it from being malicious. So the server is responsible in both cases because it has all the knowledge necessary. If the browser tried to prevent code execution then no code would execute. It can't know the original origin of the text.

beaconstudios 6y ago

you send the server text; the server sends your browser HTML. That's the difference - the server is taking the text you sent, and allowing it to escape its textual confines and become code/markup. HTML is nice enough to make this easy, where SQL servers have gone the way of parameterized queries to explicitly make this impossible (harder?)

lucideer 6y ago

> If a server sends my browser text, however, and my idiot browser executes it as code, that's also a server flaw. XSS is not the server sending your browser text, that your idiot browser executes as code. XSS is the idiot server sending the browser code that the server thinks is text. The browser's job is to execute code the server sends it: the browser trusts the server, and it's the server's job to ensure what it's sending as code is code and what it's sending as text is text.

KMag 6y ago
Since the days of phone phreaking, we've known in-band signalling is just a terrible idea. Any time a legal message token/signal/sequence in your data payload can escape data to metadata/code status, encapsulation complexity goes way up and at least one implementer is going to screw something up in a bad way. XSS was entirely predictable from the design of <script> tags and onload, onclick, etc. handler HTML tag attributes. One alternative would be to force all <script> tags to come immediately after the <html> tag (before any <head>, <body>, <style>, etc. tag), and have it be a fatal error disabling scripting if a script tag came after any other html tag except for <html>. You'd also need to reverse the way onlead, onclick, etc. handlers are set, having them set from the script side instead of setting handlers via html tag attributes. If you were extremely careful about the design, you might be able to have scripts opt-in individual functions to being handlers specified in HTML tag attributes, but the corner cases get hairy very quickly. If you need nice general libraries handling clicks, etc, it's probably best to have your scripts scan for the tags to have handlers attached rather than having the tags decide their own handlers. The are some other solutions involving unambiguous length-prefixed type-tagged sections clearly separating text and code, but those are better suited to non-textual formats, and a weird hybrid text-and-binary format (such as PDF) is another type of security minefield. Edit: formatting. Also, one of my favorite classes was a retrospective look at a variety of computer systems, critiquing very good and very bad design decisions. We looked at X11, zlib, Therac-25, Ariane 5, etc.
- andrewaylett 6y ago
  A Content Security Policy without 'unsafe-inline' is fairly close to what you describe.
  - lucideer 6y ago
    'unsafe-inline` still allows external scripts, so isn't really effective on it's own, but yeah CSP does generally solve the problem the gp is talking about.
- lucideer 6y ago

pjc50 6y ago

> If a server sends my browser text, however, and my idiot browser executes it as code That's entirely normal. There's no hard distinction between "text" and "code", and there always end up being leaks in the systems designed to keep them apart. In the case of XSS, the difference is between "text" of the webpage that you're supposed to execute and "text" that was inserted into the web page from somewhere else.

progval 6y ago

Not to me. The browser executes it as code in a sandbox, that is dedicated to that website. No harm was done outside the sandbox (if there was, it would be a client flaw); it's just the server doing bad things in the sandbox the client "allocated" to it.

BerislavLopac 6y ago

> If a server sends my browser text, however, and my idiot browser executes it as code This is literally the whole idea of how browsers are supposed to work...