5 ms·

Company forced to change name that could be used to hack websites

74 points by billpg 6y ago

rbanffy 6y ago
Bobby Tables strikes again. https://xkcd.com/327/ https://xkcd.com/327/
yodelshady 6y ago
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.
- 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...
deleted 6y ago
[deleted]
mcv 6y ago
I actually like the idea of this company name. It's a harmless way to warn a lot of insecure systems that rely on data from Companies House that their data handling is insecure. 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.
- wccrawford 6y ago
  Plus, I think forcing them to change their name means they aren't sure the rest of their system will remain secure, despite their claims. If it was, that name wouldn't be a problem.
  - lucideer 6y ago
    > they aren't sure the rest of their system will remain secure, despite their claims 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.
    - mcv 6y ago
      Which is the entire point. Lots of other systems rely on this data but may handle it in an insecure manner. This is a fairly safe way to expose all those vulnerabilities.
munchbunny 6y ago
From the article: > 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.
- nannal 6y ago
  The risk was to insecure customers, companies house services weren't vulnerable to this to begin with.
entrep 6y ago
The code in the article hero seems like an interesting approach to client side validation.
- szhu 6y ago
  Wow, I'm impressed that they picked a stock photo of code that's relevant to the article.
mercora 6y ago
sure, why should they escape user input when they can just ban various attempts as they notice them occurring...

74 points by billpg 6y ago

Bobby Tables strikes again. https://xkcd.com/327/ https://xkcd.com/327/

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.
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...

deleted 6y ago

[deleted]

mcv 6y ago

I actually like the idea of this company name. It's a harmless way to warn a lot of insecure systems that rely on data from Companies House that their data handling is insecure. 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.

wccrawford 6y ago
Plus, I think forcing them to change their name means they aren't sure the rest of their system will remain secure, despite their claims. If it was, that name wouldn't be a problem.
- lucideer 6y ago
  > they aren't sure the rest of their system will remain secure, despite their claims 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.
  - mcv 6y ago
    Which is the entire point. Lots of other systems rely on this data but may handle it in an insecure manner. This is a fairly safe way to expose all those vulnerabilities.

munchbunny 6y ago

From the article: > 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.

nannal 6y ago
The risk was to insecure customers, companies house services weren't vulnerable to this to begin with.

entrep 6y ago

The code in the article hero seems like an interesting approach to client side validation.

szhu 6y ago
Wow, I'm impressed that they picked a stock photo of code that's relevant to the article.

mercora 6y ago

sure, why should they escape user input when they can just ban various attempts as they notice them occurring...