Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
is this working hello alright thanks so first a warning my slides are not going to get much prettier than this it's kind of tough to follow so many really great and amazing user experience designers when you're the security guy I'm gonna show you
some cool technologies I promise but they're technologies that mostly do their magic behind the scenes but that's one of the great things about the Web today and the html5 platform and everything that's going on is there's awesome stuff everywhere
you look I think we're all here today and we're watching on the live stream because we're really excited about the possibilities these technologies offer but there's one group that's probably not excited about what these technologies offer
and unfortunately that's my fellow security people right almost since html5 was born you can't go to security conference you can't read the text without finding html5 listed as one of the top threats to developers one of the top first users to
enterprises etc you know it's framed as part of this out-of-control spiral of complexity on the web that's going to doom us all to endless malware and cross-site scripting everywhere and all these problems right now we security folks are kind of grumpy
by nature right we spend all of our time warning people about the bad things they're gonna happen then we make a better living every year because nobody listens to us so this is sort of to be expected but you should be asking yourself you know are they
right should I be listening to this advice is html5 really a bad thing for security on the web and I'm here to say that it's it's not I've been involved in the web and security technologies and really interested in this stuff since 1994 and
despite hearing about Chinese hackers and well second stuff on the news every night I think the state of the web from a security point of view is actually better than it's ever been that html5 is what we have to thank for a lot of that improvement in recent
years and it's putting us on a trajectory to continue to improve dramatically in the next couple of years all right at the last w3 comp I gave a talk with Scott stander a vice-like partners and we sort of talked about what's different about html5 applications
that means that everyone you know client experience designers has to think about in terms of security and today I really want to dive deep into some code and look at two specific problems show you some real examples of how you can use html5 of some of these
new technologies to solve script injection letís and to build secure mashups or to the big outstanding problems of web security and along the way I hope that I'll convince you a little bit and maybe convince some security people if they're listening
the agency ml5 is a good thing for the security of the web and it's a path forward to help make things better for all of our users so not to lack ambition alright let's tackle the biggest security problem on the web first script injection also known
as cross-site scripting or XSS which is probably what you heard of it is this is the most common application vulnerability on client-side web applications today right and very credible studies by Whitehead security of estimated as prevalent is that 90% of
web applications and I believe that and I hope if you're a web experience designer or web engineer working in this technology in 2013 you have some idea of what cross-site scripting is you've heard of it before but if you haven't in a nutshell
if somebody else gets to run script in your application it's not your application anymore cross-site scripting isn't just about stealing cookies it's about someone else gets to take over control of your application in the context of you users browser
and when you combine that with the same origin policy for JavaScript it means that an XSS vulnerability anywhere on your domain makes all the resources and assets on your domain vulnerable so they can run amok in the user's browser they can do anything
they can be your users to your application and that's not something we want we've known about script injection since 2001 is a problem on the web and we've developed these sort of you know server-side best practices to handle it we have input filtering
where we're going to try and recognize contact coming in from users from forums and other places and strip out things that look like dangerous tags or dangerous characters and we have output encoding where before we send content that might include user
generated you know code we're gonna try and encode it so that the browser doesn't see that as markup it sees it as data and one of the most common complaints you hear from the security community way back about HTML 5 is that it's gonna break a
bunch of existing input filtering is going to make websites that weren't vulnerable before now vulnerable to cross-site scripting and you know they're right that's true there are a lot of new tags there are a lot of new attributes there a lot of
new active content types in html5 that those old filters aren't going to recognize and that's something we're really trying to avoid in the standard space we don't want to make existing deployed applications vulnerable when they weren't
before but the thing is all of those filters every single HTML XSS filter that uses a blacklist today is already broken and how can I be so confident that they're all broken because stuff like that and that gets interpreted by web browsers HTML for browsers
and turned into scripts that can be used to mount to tax does your filter check for that how many browsers did you test it in to make sure that that doesn't run code on your website right so these are from a book called web application obfuscation by Gareth
Hayes Mario Heydrich Eduardo Villanova and David Lindsey there's an entire 280 page book full of stuff like that what I showed you is just the shore of a continent of horror so you know how did they fill how do they write 280 pages worth of stuff like
that what's going on and part of it has to do with what are these filters trying to do these filters are doomed from the start in the HTML 4 world because what we're trying to do is on the server side simulate the parsing and execution environment
of the browser in the client but in the past every single parts are operated differently the way that they worked was a secret every browser was full of proprietary features and tags and it was actually a feature it was a good thing to try and accept as much
bad markup as you can there's the hostels principle says be liberal and what to accept and so browsers were actually competing to do things like that it wasn't until HTML 5 that we started to see some of this change right the the security improvements
in HTML 5 actually start at the very foundations of how browsers work in the parsing engine because HTML 5 is the first of the HTML specs to define a normative state machine including error conditions for how to handle markup and so if you want to understand
for the first time you can find out and you can have some reasonable confidence how browsers parse markup and you can expect that most of them are going to work in pretty much the same way the result of this is that coercing a shambling amount of white noise
into an application is no longer a competitor feature and this is kind of a key insight that goes well beyond just parsing right because by standardizing the technology for building rich web applications html5 began a fundamental shift in the security posture
of the web as a platform right one of the biggest false charges I see leveled against html5 is that it's insecure because it's more complex than HTML 4 that's not the right comparison to make because HTML 4 was never really by itself the platform
[ ... ]
Nota: se han omitido las otras 3.976 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.