Healthcare.gov Security Hiccups

Senior penetration testers used to say that if you wanted to practice on a live Internet website and not get into any trouble, then pick a porn site. Even if you were caught by the site owners, they'd never prosecute and, if they did, the court of public opinion would be on your side.

Today it looks like there's a new candidate for honing your hacking skills: the website of President Obama's flagship Affordable Care Act.

Healthcare.gov has been subject to a barrage of attacks, both online and in the media, ever since appeared online. This week, the site has a portion of the media hot under the collar due to a few client-side flaws and an expectation that recorded attack attempts should have been scrubbed from some prefill search results.

For the public reading these stories, many are bound to think that someone's limb had been torn away by a pack of rapid wolves, and surgeons were desperately trying to sew the victim back together. In reality, it's more like dealing with a hangover from the night before, where the cure is a good old aspirin.

Essentially, two vulnerabilities are being talked about this week. The most visible is merely a reflection of how people have been trying to hack the website, and how the contextual prefill of the search box lists the most common attack strings folks have been throwing at it. It's amusing, really.

The site developers appear to have done a good job sanitizing the input (i.e., replacing potentially malicious characters with their safe HTML counterparts), but they could have probably saved themselves the present grief had they simply dropped certain strings from making it to the prefill candidate list. They appear to have applied some prefill filtering in the past to prevent common swear words from appearing, and have now (since this media frenzy started) added many of the strings more commonly associated with SQL injection since the issue was pointed out. For example, the following no longer appear if you type a semi-colon:

The second vulnerability has to do with the way the client-side script components of the website handle HTML characters as they're typed into the search box (and, no doubt, other areas of the site if you were to go hunting for them). In essence, the client-side scripts get a little confused. While potentially annoying for people having a poke at the website in their bug-hunting quest, it's nothing to be concerned about by those actually intent on using the site for what it's supposed to do.

I've heard a few people point out that the combination of these two bugs could potentiallybe exploited in a cross-site scripting attack, but you have better odds of being hit by a meteorite.

For all of the faults in the site that have been pointed out in the past month, this latest batch only merits a one-shoulder shrug.

-- Gunter Ollmann, CTO IOActive Inc.