Company forced to change name that could be used to hack websites
theguardian.com
theguardian.com
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?
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.
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.
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.
However, this just moves the problem around. While it could be argued specifying JS out-of-band would make it less likely for XSS to occur, anywhere that JS is specified is still likely to be programmed dynamically, with external inputs (db values, etc.), so the risk remains.
For example, a lot of modern XSS leverages innerHTML rather than server-side markup insertion. e.g.:
element.innerHTML = fetchData(endpoint);
The proper solution, as a sibling commenter mentions, has already been specified: it's CSP and it works well if used.
Presumably element here is <head> or later, so scripts wouldn't execute. Also, you'd presumably define things such that new <script> tags would be ignored if they were parsed temporally after the first non-<stript>, non-<html> tag, regardless of their position in the DOM, so that you'd need to explicitly eval any dynamically loaded scripts.
Thanks for the pointers to CSP. I'll have a look. In any case, the default should have been to ovoid in-band signalling, and perhaps have a CSP-like mechanism to relax security constraints. Sure, hindsight is 20/20, but precedents in phreaking are obvious.
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.
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.
This is literally the whole idea of how browsers are supposed to work...
You need to be able to handle data that looks like that. If you're not, and your application interprets it as code, then it's insecure and you should fix it.
It may well be that, but it's also worth noting a company name will also be proliferated to many places outside of their systems.
> A Companies House spokesperson said: “A company was registered using characters that could have presented a security risk to a small number of our customers, if published on unprotected external websites. We have taken immediate steps to mitigate this risk and have put measures in place to prevent a similar occurrence. We are confident that Companies House services remain secure.”
No, if you were that easy to inject, your site was not secure to begin with.