W3 conf hill-html5-security-realities

Editor's Notes

• #2: First, let me apologize that my slides aren’t very pretty – it’s tough to share a stage with so many of the most talented front-end engineers in the world and be the security person. But to that point, we’ve seen a ton of really amazing stuff here so far, yesterday, this morning, and with more to come. I think it’s safe to say that all the developers in the room are really excited about the possibilities of HTML5 and the Open Web Platform. But there is one group of people that isn’t so excited about all of this: the security community.
• #3: Almost since HTML5 was born, you can’t go to a security conference or read the security tech press without finding HTML5 at the top of almost every list of threats. It’s framed it as part of an out-of-control spiral of complexity on the web that’s going to leave everyone vulnerable to more malware, more application-level compromises and more enterprise risk. Now, security people are grumpy by nature. We are constantly warning people of dangers ahead, and we’re making a better living than ever because nobody ever listens. So, when it comes to HTML5, should you listen? Well, I’m here to say that no, in this case you shouldn’t. I’ve been working on Web technologies and in security since 1994, and despite hearing about Lulzsec or Chinese hackers on the news every week, the security state of the Web today is better than it has ever been. In particular, we’ve made very large advancements in the last few years, largely due to the rapid advancement of HTML5 and the Open Web Platform, and I think the next few years are going to continue that positive trajectory.
• #4: At the last W3Conf I gave a talk with Scott Stender of iSEC Partners where we talked at a high level about some the ways HTML5 is changing security for modern web apps and what to be aware of. This time I want to show some real code on how to use new standards to tackle two of the biggest problems in Web security: solving Script Injection, and building secure mashups.Along the way, I hope I’ll convince you, and maybe, if some security people are watching, them, that HTML5 is a big step forward in security for the Web platform.
• #5: So, not to lack ambition, let’s tackle the biggest security problem on the Web first: Script Injection, also known as Cross-Site Scripting or XSS.
• #6: This is the most common vulnerability on the Web – some studies have estimated its prevalence at 90%, and I believe that. One of the things HTML, of any version, is not good at is separating data and code, so any dynamic application tends to have script injection issues unless you’ve specifically architected your app to avoid them.
• #7: I hope that most everyone who’s a web developer today already has some idea of what XSS is, but in a nutshell:If somebody else gets to run code in your WebApp, it’s not your WebApp anymore. And the Same-Origin Policy for JavaScript means that if there is an XSS vulnerability anywhere on your domain, everything on your domain is vulnerable. The attackers can take advantage of a single weakness to run amok in the browser, impersonate your users, and do anything they can do.
• #8: Script Injection has been a known problem since 2001, and we’ve come up with some server-side best defensive practices to prevent it: Input filtering, where we attempt to strip dangerous characters or tags from user input before we use it in markup, and Output encoding where we attempt to encode user data so that it isn’t treated as markup by the browser.And one of the oldest security complaints about HTML5 is that it is going to break many existing XSS filters. If you have a blacklist filter that tries to strip specific tags and event handler attributes, HTML5 introduces a large number of new tags and features that won’t match your old rules.
• #9: And, yes, this is true, and introducing new security risks into existing legacy systems is something we try really hard to avoid as we build new standards. But you know what? Every single blacklist filter for HTML4 is already broken. How can I be so confident? Because things like this:
• #10: And this:
• #11: Get interpreted as valid script in HTML4 in some browsers and can be used to mount attacks! Does your filter block those? How many browsers did you test it in?
• #12: Those examples are from a book called Web Application Obfuscation by Gareth Heyes, Mario Heidrich, Eduardo Vela Nava and David Lindsay. An ENTIRE 280 PAGE BOOK full of stuff like that. Those examples I showed you are only the shore of a Lovecraftian continent of horror.
• #13: How could they fill 280 pages with this stuff, and why are all of our XSS filters broken? They work in very limited contexts, but in a broader sense, they were doomed from the start, because an XSS filter is a server-side attempt to simulate the client-side parsing and execution environment, but before HTML5, every browser did this differently, how they did it was a secret, browsers were chock-full of proprietary features, tags and syntax, and accepting bad markup was actually considered a feature, in the tradition of Postel’s Law.
• #14: This is all to say that the security improvements of HTML5 start at the very foundations, because HTML5t’s the first version of HTML to specify a normative state machine for parsing, including handling error conditions. Yes, there are new tags and new syntax, but if you want to know how browsers are going to parse markup, for the first time you can find out, and you can have some reasonable confidence that different browsers are going to act in a mostly consistent manner.
• #15: The result of standardizing parsing is that generously coercing shambling mounds of random line noise into an application is no longer a competitive feature! And this is an insight and an outcome that doesn’t just apply to parsing –
• #16: By standardizing the technology for building Rich Web Applications, HTML5 began a fundamental shift in the security posture of the Web as a platform.One of the biggest false charges leveled against HTML5 is that it’s insecure because it’s “more complex than HTML4.” But that’s not the right comparison to make. HTML4 was never by itself the platform of the Web. The Rich Web Application has been with us for a decade, but it was built in terms of plugins – in Java, Flash and ActiveX.
• #17: If you’re the creator of one of these proprietary rich web app platform whether browser or plugin, you need to attract developers, so you live or die by how much you let developers do, not by how many security restrictions you put on them. You compete for developers and once you have them they’re locked in. If you’re not happy with Java’s security record, you have to re-write your whole application to switch. If you’re a user, you can’t switch – you have to take it or leave it. On the contrary, if I was using an HTML5 app and my browser had a security record like Java, I could switch in a second, and the app developers wouldn’t have to change anything.
• #18: So the incentives of the Open Web Platform are different than they’ve been: Proprietary platforms compete for developers by offering features, and they can keep them because switching costs are high. On an open platform, switching costs are low, so implementers have to compete for users by offering them quality, which includes security.
• #19: But enough soap box ranting – we were talking about solving script injection.
• #20: And even though we finally have some hope of an accurate simulation of the browser in HTML5, that’s still not a great strategy. It’s complex, it’s not future-proof, and it misses what’s called DOM XSS, vulnerabilities through data flows that can’t be filtered at the server because the server never sees them.If script injection is a security issue at the client layer, why not solve it in the client?
• #22: Maybe you remember the scene in the Odyssey where they’re about to sail past the Sirens. Odysseus knows that he’ll go mad from the siren’s song, so he orders his crew to tie him to the mast and, whatever he says later, not to untie him.That’s kind of what CSP does. It lets an app tell the browser to tie it to the mast.
• #23: This is an example of a CSP header, and you can see it’s pretty straightforward. We just list the origins that are allowed to load content.The difficult part here is that to get the full benefit, you can’t use inline script or css, and that’s pretty problematic for existing apps.
• #24: We can …And CSP has a reporting feature, which makes deployment much easier, because you can measure what’s going to happen and build correct policies before you start enforcing them.
• #28: So in CSP 1.1, we are working to fix this, by allowing whitelisting of inline scripts and css, along with other features like controlling the types of plugins that can run, and adding reporting to existing browser anti-XSS filters. So this is a great start on preventing XSS attacks that you can start using today, but there’s one other up and coming technology I want to touch on – and that’s HTML templates.
• #30: So HTML templates are a new spec under development in the WebApps Working Group that allow you to declare templates as first-class client-side objects. Instead of dynamically building markup using strings concatenation and innerHTML, we’ll have a pattern that has the potential to be both faster and offer much better security against script injection.
• #31: What this boils down to is that:
• #32: OK, so we’ve solved XSS, which is a pretty good day’s work– but I also promised I’d show you how to build secure mashups in HTML5 – another thing that security folks like to say can’t be done.
• #33: So what’s a mashup? It’s when you include content from multiple sites in a single app. And I think we’re all familiar with anonymous mashups, like putting Craigslist apartment listings onto a Google map, but what a lot people probably don’t think about is that almost every major app today is part mashup – and moreover, they’re authenticated mashups. With features like advertising, analytics and federated login, we’re sharing authenticated user data across origins at most places we visit on the Web.
• #34: So Flash allows us to do this, using a policy file called crossdomain.xml, which defines ACLs for foreign SWFs. This policy file lets SWFs loaded from www.example-analytics.com to make requests, with cookies, and read the results, from www.foo.com.
• #35: But we security folks are kind of cynical, we’ve seen it all. And my friend Jan recently quippped: Give someone an ACL and they’ll put in a *.So what happens if you put a * in crossdomain.xml?
• #36: Oops.. If you put * in your master policy file, you just allowed any malicious SWF anywhere on the Internet to access all your user’s information. Game over. So that’s not great…
• #38: And the answer is that, since the beginning of the Same-Origin Policy, there’s always been a loophole. If I load content, and it sources script from another domain, that script becomes part of my application, effectively allowing us to read that information across domains and use this as a communication channel.
• #40: But still, everyone thinks this is OK. We security people warn that this is dangerous, but nobody thinks anything bad is going to happen, they trust the people they’re getting this script from.Until two weeks ago…
• #41: When Facebook broke the Internet. Did anyone see this? If you went to any of thousands of sites on the web, instead of seeing that site, you got a Facebook error page instead. Do you want to see the one line of code the broke the Internet?
• #42: Well, this is the mashup pattern for Facebook Connect. So one bug here, and your application is at its mercy. But still, this was just a bug, it wasn’t an attack.
• #43: Hmm… This is what Facebook had to say, just a week after the connect fiasco. Now these aren’t related and I’m sure that Facebook has really good security measures in place to make sure that a compromise of a developer workstation doesn’t propagate out to impact code on the live site, but it should give you pause.The more we use insecure patterns like script src to connect the web, the more fragile we make it, and the more we make an individual API \\a single point of failure for the security of huge parts of the web, the harder the bad guys are going to try to exploit it.
• #47: Script src gives you code that you have to trust, but CORS gives you data that you can validate.
• #48: And it doesn’t introduce any new Cross-Site Request Forgery attack surface.
• #53: And so, in just a few lines of code, we’ve locked our legacy mashup into a strong sandbox, and only let it pass notes. If it breaks or gets hacked, it can’t reach out and affect rest of our application.
• #54: But there’s more to this than I first realized….I mentioned this pattern for safe mashups at the last W3Conf in 2011, and I’m sure I’m wasn’t the first to have done so, but I didn’t realize how important it was until I saw a talk by Devdatta Akhwe at last year’s USENIX Security.In one of those brilliant insights that seems obvious once you’ve heard it, Devdatta realized that this wasn’t just a useful trick for legacy mashups – that it is actually a fundamental building block allowing privilege separation in HTML5 applications.
• #55: What he said was basically, what if I treat my own code, and the libraries I host on my own domain, as being just as potentially dangerous as that foreign mashup? After all, if I’m building a complex app with tens of thousands of lines of JavaScript code, surely there are some latent bugs in there.And actually, the vast majority of that code doesn’t even need to do sensitive things like access the user’s cookie or perform transactions. We can apply the same architectural principles of privilege separation we use for architecting browsers or operating systems to our HTML5 applications using this iframe plus postMessage pattern.
• #56: And he found that, for real-world applications using off-the-shelf libraries, by changing just a few lines of code, it was possible to reduce the trusted computing base of these applications by 95%, isolating all of those latent bugs into strong, browser-provided, same-origin sandboxes. So go check out this paper. If people pay attention to it, I think it has the potential to be one of the most important computer security papers of the decade and hugely reshape the risk profile of client-side WebApps.
• #57: I could go on about many more features, but I think that’s a pretty good start. I hope I’ve convinced you that HTML5 and the Open Web Platform are improving the security of the Web ecosystem. Rich Web Apps aren’t new, and HTML5 offers big security improvements compared to the proprietary plugin technologies it’s actually replacing.