Dan Kaminsky's Blog

(Hehe.  This is a fun post.  Hopefully it annoys the W3C and Security communities equally.)

Just to go on the record: I’m just not all that concerned with new security threats from HTML5. Frankly, minus WebGL, HTML5 in 2010 gives us roughly the functionality that Flash gave us in 2004, but with oddly less polish.  (I’m not kidding:  They’re still trying to figure out how to correctly implement full screen video.)

From a security perspective, that means whatever is scary about HTML5 has already been in place, in 99% of browsers, for half a decade.  Not that that means we’ve attacked, or fixed it all — we in the open security community aren’t exactly known for our speed in finding issues.  But I can’t say I’ve seen much in HTML5 that’s made me nervous, at least relative to problems that already exist in HTML4 and Flash (to say nothing of Java).

What does however bother me is the lack of security technology in HTML5.  The performance guys got goodies.  The artists got goodies.  Even the database guys got goodies — they’re getting SQLite in every browser!  Meanwhile, Cross Site Scripting and Cross Site Request Forgery attacks remain endemic to the web, and fixing them remains embarrassingly expensive.

The real problem with HTML5 is not what risks it adds.  It’s what risks it doesn’t even attempt to remove.  I don’t think we can even blame W3C for this — who, in the security community, has been willing to spend the years necessary to push a spec through?  Thus far, not enough of us.

In the long run, if we’re going to actually fix things, this is something we’re going to have to do more of.  I of course have my own thoughts on what to do about these endemic attacks — I think we need better session management — but actual participation is probably more important than a random slide deck and some code.

(Slight edit:  Yes, the browser manufacturers have been playing around with some technologies to address these issues — Microsoft, with their Anti-XSS Filter, and Mozilla, with Content Security Policies.  Are either technologies looking to be on the larger standardization path?  Not as far as I can tell.)

Interestingly, I just watched a talk at Black Hat Abu Dhabi about a particular realm of failure in Web Session Management:  Robert “RSnake” Hansen and Josh Sokel’s “HTTPS Can Byte Me“.  Their point is that the HTTP version of a site actually has quite a bit of control about the credentials presented to the HTTPS version of a site — and that this control, while not overwhelming, is a lot more powerful, and troubling than expected.  The two attacks I liked best:

1) If you have a site with a wildcard certificate, and that site has an XSS attack reachable irrespective of Host header, then an attacker w/ MITM capabilities can read content from anything valid under the wildcard.  Put another way, if you have supersecure.mozilla.org and *.mozilla.org certs, and the *.mozilla.org site gets hit, supersecure.mozilla.org is somewhat exposed. (I’m using the example of mozilla.org, because apparently this actually affected them).

2) Since HTTP sites can write cookies that will be reflected to HTTPS endpoints, and since cookies can be tied to certain paths, and since servers will puke if given too long cookies, an HTTP attacker can “turn off” portions of the HTTPS namespace by throwing in enormous cookies.  Cute.

Ultimately, these findings have increased my belief that we need the ability to mark sites as SSL-only, so they simply don’t have an HTTP endpoint to corrupt.  The melange of technologies, from HTTPS Everywhere, to Strict-Transport-Security, to the as-yet unspecified DNSSEC Strict Transport markings, become ever more important.