 Thank you very much, everyone. It's nice to see everyone so excited straight away before we even said a word. But yeah, today I'm going to be talking about the security risks of Web 2.0. I'm really, I'm not going to be deep diving into anything in particular. But what I'm trying to do today is give a wider coverage, is give a wider coverage than maybe some other presentations on this topic. So I'm not going to talk about just one or two different vulnerabilities. I'm actually going to try and squeeze ten of them in. So I don't know if that makes me mad or not for trying to do that, but that's what we're going to cover today. So firstly, there'll be a very quick Web 2.0 definition, looking then at common vulnerabilities, some of the differences between Web 1 and Web 2 for those vulnerabilities. Why a security analyst job, i.e. my job, is more difficult when it comes to Web 2.0 applications and how to prevent these vulnerabilities in your own code. So my name is David Rook. I'm a security analyst for a company called Relics Payments in Ireland. We're a payments process in company. We do kind of in excess of, I think it's six billion euros worth of credit card transactions each year. I have a couple of different websites. Security Ninja is my blog. I do a lot of work with OS, contributing, helping set up conferences, speaking at conferences and so on for them. I'm the security advisor for the Irish Internet Association. We have a web development working group where we try and help small development companies in Ireland understand how to deliver development projects and I help them understand security issues. I've also found a few security issues in Facebook and we'll look at one of those later on as well. So kind of, like I said, I just wanted to say upfront what this presentation is and what it isn't. So it's not going to be a technical discussion about Web 2.0 technologies and architectures. It will be a discussion about vulnerabilities and Web 2.0 applications. There's no zero days, no new attacks or so on here, but there's also not just a discussion about cross-site script and a SQL injection. We're going to look at, like I said before, 10 different vulnerabilities today and how you can prevent them in your own code. So kind of on the screen there is Tim O'Reilly's quite famous quote, I think by now, but what Web 2.0 is. But instead of trying to run through that, I've just got this image here which probably allows you to understand the types of websites we're talking about. So Facebook, Wikipedia, YouTube, those types of websites, the kind of sites we're talking about today. So some of the key points about Web 2.0 is that we've kind of switched away from people visiting websites to read site-provided content to the sites essentially just becoming a framework that users come along and fill in. So things like social networking sites and YouTube. There's a desire to have a desktop look and feel to those web applications. There's also a feeling that kind of everything can go online now. So with things like Google documents, you can do all your word process in spreadsheets, et cetera, online. There's also things like iOS, which is a full operating system that you can use within your browser. There's a feeling to have kind of a syndication of content as well. So a user doesn't want to come back to your page 10 times a day to see if you've made any updates. We use things like RSS and Atom, and I guess even websites like Twitter nowadays to allow people to see updates to your site quickly. And another key point, which I think will become a bigger problem in the next public year or so, is the offline storage of data and state. So probably Google Gears would be the leader in this at the moment where it will essentially create, update and delete databases on your local file system. So there's kind of no concept of on or offline working with that. And if HTML5 ever gets approved, then that will also be bringing that kind of functionality along as well, creating these databases, allowing the sites to create databases on your file system is not particularly something I feel comfortable with. But if you want to know more about the issues around that, come and grab me afterwards. I've got a presentation I did last year that I can show you on that. Kind of for time reasons, I'm not going to step through everything on here, apart from kind of just to point out the last two points at the bottom. Web 1.0, we had poor security, and in Web 2.0 we're kind of repeating the same issues. Really, you know, some of the key points off there, you know, from a user point of view, their web experience has changed from come along and reading content to come along and providing content. There are different technologies there, different security issues. So, the vulnerabilities we're going to look at today, probably by name, a lot of these will be familiar to people. The cross-site script and cross-site request forgery, SQL injection, authentication, authorization, flaws. And I guess if I was sitting in the crowd now, I'd probably be thinking that they are the same as Web 1.0. Well, in name at least, they're the same. But we're going to look at how they're exploited differently in Web 2.0 today. And we're going to look at three vulnerabilities, which I think are kind of Web 2.0-specific. So cross-site script and worms, feed injections, so just on the cross-site script and worms, I'm not going to step through SAMI, like probably everyone else that's the last four years. I've got a different cross-site script and worm for us to look at today. And then some of the problems that can occur with mashup and widgets websites. So first up is cross-site script and I think by now everyone knows that it's not a new vulnerability, but it certainly has the potential to be worse in Web 2.0. And these flaws occur whenever an application takes externally supplied input and uses that as an output into the browser. And there are kind of three main types of cross-site scripting. So I've reflected cross-site script and attack. And what I've done on these three points is I've got just a line of vulnerability and an example of a bit of attack code there. So reflected cross-site script and attack occurs whenever the user supplied data is reflected back to the user in the browser immediately. So it's all on the client side. It's dynamically created on the client side. So if you're only relying on server side protections then it won't help you here. The second type is a stored cross-site script and attack, which I guess kind of by name. It implies what it is. So you store your malicious code on the server side to a database. And then when someone comes and views maybe your blog, every time someone comes and views that it'll execute the code. And we'll look at the cross-site script and worms later, which are essentially stored cross-site script and attacks. And then finally we have a DOM-based cross-site script and attack. And again this is occurring on the client side. And the example we've got there is if we've got a URL for example site.com and we've got a name equals value. Now if the name has David in there, then the bit of code underneath that URL there is going to pull that out and write it into the page so the website might say hello David. But if we don't validate that name value before we pull it into the page and inject it into the page is DOM, then we can open up to DOM-based cross-site script and attacks. So how can this get worse in Web 2.0? Well, we've just mentioned DOM-based cross-site script and attacks and DOM manipulation to give kind of a dynamic interactive field to Web 2.0 applications is kind of becoming more and more vital all the time. So if we think when we make these updates to the DOM, if we're pulling in data from external sources and injecting it straight into the DOM, then we could be opening ourselves up to security issues there. And we're going to look at example in a second of that. We have user-controlled data in more places. The web experience for a user anymore isn't just coming along and putting data into a search field or form field. The website as a whole, things like Facebook for example, is pretty much built from user-supplied data. So from a security point of view, validating all that data and making sure you don't get caught out with security issues is more difficult. We also have now self-propagating cross-site scripts and attack codes. So the cross-site script and worms that I was talking about, we've got a section later on on that, but really they're stored cross-site scripts and attacks and we'll look at again an example later on. And really kind of tying back to that first point now where we bring in data from data streams like JSON or XML. I think you have to assume that they could be malicious, but I would say a lot of people probably don't. So if you're pulling that data and inject it straight into the DOM, then your users can be exploited. So you want to just make some of those points a little bit clearer. Because we have a very dynamic DOM in a lot of these applications we'll use things like document.write or an eval statement to pull in data and inject it into the DOM. But the data you pull in to your eval or your document.write, if you don't validate that before you use it, then you could be injecting the tag code into the user's DOM. So in the example we've got here, kind of the top half of the screen, we're making an XML HTTP request. So we're just making a request for data. And near the bottom is just the bit of code that's actually getting that data for. So it's going through a proxy, so we're going to an off-domain location to grab that information. And essentially that's a bit of code missing out of there for me to try and fit on the screen. But essentially you can see near the bottom we have an eval statement and that's where we're passing that externally data into. So that'll execute that for us. So if you don't validate that before you use it like we aren't here, then you open yourselves up to an attack. So the next vulnerability is cross-site request forgery. And I didn't get chance to come into the talk previously, but I guess anyone who was in the cross-site request forgery track already knows how bad this is and how bad it can get. So really what I'm talking about here is again it's not new, but it has the potential to be worse. And really what you're doing with the cross-site request forgery attack is is instead of executing malicious code on the client side like we have in cross-site scripting, you're making a request, forcing a request to be made on behalf of that user without them knowing about it. So kind of just to reiterate that it's important to remember that cross-site scripting is not cross-site request forgery, they are two separate attacks. So I've got a real simple example here just in case anyone didn't make the last talk or not quite sure what cross-site request forgery is. We have a website here called NinjaRental.com. So you come along, you put your username and password and you hit submit. The request is sent to the server. The server will authenticate you and send the session ID back. So when that user is using the NinjaRental site and he wants to rent a Ninja, he wants to just rent the regular Ninja for a hundred pounds. He doesn't want to hire Chuck Norris. I probably wouldn't know that he's probably a little bit volatile for my liking, but the guy chooses the regular Ninja for a hundred pounds hit submit. It sends that request to the server. The browser sees that, oh yeah, I've already got a session value for that so he doesn't have to re-authenticate. The browser just sends that value along with the request. His account is debited in the back end and then he gets a Ninja. What if he's still authenticated to that site? I get him to come along to my dodgysite.com. And whilst we might be laughing at Agent Smith there to start off with, I think ultimately he's going to have the last laugh here. Because whilst you might think we can't make this request from this other site, we can use some tags like an image source tag or an iFrame source or a script source tag to bypass a protection mechanism called the same origin policy which should have prevented this attack happening but by design those three tags allow that attack to happen. So when the user comes on this site, the funny pictures of Agent Smith load up but in the background the browser sees that it's got to make this request to NinjaRental.com as well. And you can see basically what it's doing is it's making a request to hire that Chuck Norris Ninja. So he's now going to have a thousand pound debited from his account without him ever actually sending that request. And again the browser being helpful just sees that request being made in the background, sees you've got a session value for it and sends that long and the request is made. So some people look at those examples and say well that's probably a bit too simple to work in the real world. We're going to take a look at an example in a minute where an attack almost the same as that was being exploited against Gmail for about 18 months I think before it was fixed. So what can make this worse in Web 2.0? Well we can do attacks using XML and JSON. I'm going to look at a JSON based cross site request forgery attack in a minute. They can be a little bit tricky to do but they're certainly possible. And one of the biggest issues with Web 2.0 is that cross domain access is essential. When we look at things like mashup sites they are essentially a cross site script and attack in the way that they're built and they have to allow that cross domain access. I think talking about the mashup, I think Douglas Crockford once said that they are kind of built as a cross site script and attack because everything is cross domain request. And then really like I mentioned before same origin policy isn't going to protect you. Whether we were still relying on same origin policy or not we're going to see less and less protection from that going forward. So things like the XML HTTP request and even JSON data should only be called from the same domain but again we're going to look at in the second how you can get around that as well. So firstly a very simple real world example of a cross site request forgery attack against Gmail that essentially brute forced a password reset against your account. So again it was using the image source tag and the iframe source tag so again we're starting to see similarities to the example earlier. So what the researcher found was that he could make these requests directly to reset the password with Google. So it has to provide an old password so your current password and then the password he wants to reset your account to. Now normally when you do the password reset with Gmail you have to do a capture but by making this request directly he could bypass the capture system. So he could brute force those values and try and reset your password for you. As I said I think it took around 18 months I think from this guy first reporting it to when it actually got fixed. And then the next kind of JSON based attack I'm going to look at is also against Google. I'm not trying to beat up on Google here. Just like later on I'm not going to try and beat up on Facebook but they've got the best examples of these attacks so far in my opinion. So normally as I said the XML-HCDB request should only be able to pull in data from the same domain location and the same for JSON. We shouldn't be able to request data from an off-domain location but that's not very web 2.0 friendly. We mentioned before that we have to allow that cross-domain access. So we have a thing called JSON callbacks and what a JSON callback allows you to do is to wrap the JSON data within a JavaScript function so you can make that cross-domain request or grab that data, the JSON data from a separate domain. So what a researcher found out was that he could use this to his advantage and steal your Google contacts. Unfortunately he only used it as a proof of concept so he didn't really steal your contacts but obviously other people could do. So really at the top of the screen there we have the JavaScript function called Google and we're waiting for the JSON data to be wrapped in there essentially. When he receives it he's just going to do a document.write out your contact information to the page there. So at the bottom we can see that there's also a URL to Google Docs so normally what this URL would allow you to do is when you're using Google documents you should be able to view your contacts whilst you're doing it. But the researcher found out if he put the callback parameter on the end of the URL, wrap that within a JavaScript function whenever you come to his page that code would execute grab your contacts and then in this case he just write it to the page but he could have sent that anywhere he wanted. So SQL injection, again not a new vulnerability, it's been around for a long time and what we're seeing now is probably a different way of exploiting SQL injection or a different motive for the attack in particular. So again it's not new but it's potentially worse. And really what a SQL injection attack is, it allows an attacker to inject his own bit of SQL into your back end SQL query. So we have a really simple example here where we're just going to take in a username from the user and we'll do a select star from users where the username that the guy's provided. So if he provides a one or one equals one, the example that probably everyone's familiar with, then that query will give me all the user names where it's one or one equals one. So give me all the names where it's equal to true. And again this is a real simple example but we're going to look at a real-world exploit in a minute which wasn't too much more complicated than this. So again that was a simple example but SQL injection's been used to steal large amounts of data, generally cause chaos on the Internet through different means. So card systems, they lost 40 million credit card numbers through a SQL injection attack. We've seen automated SQL injection attacks compromise tens of thousands of machines by exploiting vulnerabilities on the desktop. We're going to look at one of these attacks that was, it's only about a week and a half old in a minute as well. And when I try and give people a measurement of how many of these vulnerabilities were seen every year, I tend to use the amount of CVE numbers issued and every different vendor will give you a different statistic on how many SQL injection attacks occur every year and so on. But for me I find the CVE numbers quite useful. What's also useful is there was a great interface so if you just do a Google search for CVE statistics there's a great way to search for these itself but really the point is that of the CVE numbers issued in 2008 and 2009 20% of all those vulnerabilities were SQL injection attacks and kind of following on from that a bit in 2008 and 2009 so far cross-site script and SQL injection have accounted for roughly 33% of those vulnerabilities back in 2006 they accounted for less than 1% of all of the CVE numbers issued so you can see that there's a definite switch in focus from the attackers. And from my point of view SQL injection is the inspiration for my favorite XKCD comic so I don't know if everyone might have seen this before but really what's going on here is the mom receives a phone call from the school they're having some computer trouble so the mom says oh dear did my son break something they say well in a way and they say did you really name your son Robert you know drop table students so she said yeah that's little Bobby tables and if you go to Facebook the Bobby tables account is also mine as well I don't know whether that says a lot about me or not but really the mom says well you know that's your fault make sure you sanitize your database inputs and that's only a simple comic it actually makes a very good point before you use any externally supplied data or any data in your SQL queries make sure you validate it first. So in terms of web 2.0 SQL injection I think for the time being will still continue to be used for data theft bypass in authentication systems you know drop in tables and someone like Bobby tables mom has just done but what we're also seeing is if you think of things like flash and kind of JavaScript as technologies that users have to have enabled nowadays to go and use these kind of web 2.0 sites well the attackers know that just as much as we know that so what they're starting to do is exploit the fact that people will need flash or will have flash and JavaScript enabled when they come to these sites I mean it's okay as security guys telling people you should use no script but most of the sites the average user use nowadays will be completely broken if they go there with no script turned on. So we're seeing SQL injection vulnerabilities not being used to steal data not directly but to inject malicious flash files into sites that then when a user comes to the site views the flash video it exploits the floor in the Adobe flash player. We're also seeing people injecting malware serving JavaScript as well and we'll look at an example in a minute from about a week and a half ago of an automated attack trying to inject this malware serving JavaScript and it doesn't kind of matter how you're transmitting your data around as long as you take externally supplied data and put it into your SQL query in the back end it doesn't really matter whether you're doing that through JSON, XML, SOAP, whatever you want to use. So firstly a simple example recent example of an authentication bypass SQL injection attack. So what this guy found was that in this server called alumni server it would take in two values from the user take an email address and a password value and then use them directly in a SQL query without doing any validation. So what he did is he put his email address in there single quote parenthesis or one equals one so so far he's saying pick an email address where it's equal to true and then the slash star in my SQL actually says essentially ignore the rest of that so it doesn't have to provide a password value. So he's just put essentially any email address or one equals one ignore the rest of it and he's bypassed the authentication system. So like I said even though the kind of one equals one example probably people get fed up with seeing that sometimes it is in the real world so they're very simple attack there. Now this one I'm not going to try and step through all the white SQL stuff here at the moment there's a lot of it there but essentially this was from I think it was about a week and a half, two weeks ago and the bit in orange on the screen there is really the important thing to look at here and what this attack was doing it was automatically trying to find SQL injection vulnerabilities in websites inject this script tags when anyone came and viewed the site it would basically make a request to execute this JavaScript file and then try and exploit the office web components vulnerability which I think even now might still be unpatched and at the time of me writing this presentation the file contained two URLs and the code it tried to push down was only being picked up by 15 of the 41 virus scanners on virus total and that was on the 16th of July so you can see that you know people are attackers know that people have to have you know the ability to execute JavaScript when they come to pages so they try and exploit that as well. So next up is cross-site script in worms we know that cross-site script in itself isn't new to web 2.0 and I guess there's an argument whether cross-site script in worms is or isn't because essentially when he exploited MySpace it wasn't a web 2.0 site but he used web 2.0 technologies like XML, HTTP request for the exploit now like I said I'm not going to step through the Sammy code today but I would say I'm definitely going to have a read of it because he did some quite clever things when he exploited MySpace there. I do feel a little bit obliged to mention Sammy because I think that it was probably the first big example of cross-site script in attacks let alone cross-site script in worms in my opinion. So he did this four years ago and he managed to exploit over a million profiles in fact a million profiles in about 24 hours and even in 2009 Sammy is still a hero firstly because he's not really being eclipsed in terms of the amount of infections he's got but if you do a Google search for site MySpace and I think the whatever line of text he injected something like above all Sammy is my hero you'll still see reams and reams of profiles that still have that text not the JavaScript in there anymore but that text in there most notably actually Hulk Hogan has got that now I don't know whether I would go exploit in Hulk Hogan's MySpace page but Sammy managed to do that so I guess if I was sat in the crowd now I'd be thinking well Sammy's I'll tell me about something new. So I managed to kind of find something a bit more recent the Stork Daily or I think it was also referred to as the Mikey worm that infected Twitter in April or Easter weekend and really the problem here was that on your Twitter profile you can put your URL into the page and they weren't validating that URL field correctly so what this guy managed to figure out was he can put his storkdaily.com URL in there throw a script tag on the end whenever someone come and viewed that would execute and so on and so on and affect that profile so what we're going to do is step through some of the code or the most important points in the code at least anyway here. So firstly what he did was to grab your authentication token so at the top there we've got a regular expression where he's just going to grab your authentication token because he needs that to make two requests on your behalf which he's going to do in a minute in the middle there as well he had an array of tweets so he wasn't going to use the same tweet for everyone I don't know if that was to try and you know evade people picking up on us as an exploit or something like that but basically what he would do is he would pull one of the tweets out of that array and then use that to update your page with one of the posts in a second and then at the bottom there he's got his storkdaily.com URL with that script source on the end which again he's going to use to inject into your profile in a minute. So like I said he makes two requests and obviously he updates your status with one of those tweets out of his array so it passes along the authentication token that he grabbed he takes one of those tweets, updates your profile and then secondly he makes a second post to change your account settings to include his attack code so again he's passing the authentication token he injects that code into your page anyone comes along this should all execute on their page and so on and so on. I think he got like 17,000 infections with this storkdaily worm they fixed it and he did another worm the day after I think that's that was the Mikey worm I think he exploited a different flaw pretty much the same thing in Twitter two days in a row. So just two more extra points there as well he needed to have your screen name to make a post on your behalf so again he's got another regular expression there where he pulls your screen name out of the meta content field so he can take those updates on your behalf and then lastly at the bottom there he takes your username and cookie and sends it off to another domain of his you know why not if you can do take everything you can get that's not my professional opinion of course. So how will this get worse or how can this get worse? Well some of the worms that we've seen so far rely on kind of some quirks in browser behavior so first if you could get a worm that's fully supported by all browsers I don't know how easy or hard that is because a lot of websites aren't supported by all browsers but if you can get your worm code to be fully supported across all browsers and build a worm that is kind of site or floor independent I mean you've seen the storkdaily code there and if anyone's seen SAMIs code you'll know that they were written very specifically for a specific floor and a specific site. If you could find a way of writing a kind of a universal or generic script in worm then you could have whatever you want to call it an intelligent hybrid super worm. Now PDP and Billy Hoffman have done some great research on this I'd recommend if you want to learn more about this specific issue take a look at it but really what they're proposing is if you can build this kind of generic worm code that can go to sites like xss.com and I think there's an area on rsnakes forum as well that talks about new cross-site scripting attacks but on the xss.com if you go there it not only tells you the site that was exploited but I think you know exactly where the floor is and so on. If you could go to that site pick the top 50 off and go and automatically exploit all of those with the worm similar to SAMI or storkdaily then you could be talking millions millions of people infected depending on who you're exploiting and then lastly one of the things that I don't think we've seen on a wide scale yet is using cross-site scripting worm infections for distributed denial of service attacks. If you think SAMI essentially had a million plus browsers under his control at one point or another now what if he would have used every one of those to make a hundred or a thousand requests to your website. You're talking the kind of traffic that not many websites are able to handle you know hundreds of millions of requests. So we've not really seen that yet but it is possible if you've got a big enough amount of people infected then people might use it in the same way as they would use a traditional kind of botnet. So the next thing I want to quickly look at is feed injection. So like I said at the start with kind of web 210 we don't want people to have to come back to our site every half an hour to see if we've made an update to our block. We want them to be able to pull that down automatically with things like rss and atom and using readers to pull that down. Now the problem is again kind of like with any of these problems if you pull that data down and use it without validating it then you open yourself up to attack. So we kind of have two kind of main differences between readers. Ones that are either web browser based or web based or ones that are on the desktop and there are kind of clear differences between the security issues between the two of them. Well when you're in the browser you're a little bit limited to the kind of damage you can do to the user. Things like cross-site scripting, cross-site request forgery, they're possible through remote zone risks as I call them. So the remote zone readers whilst you're in the web browser you can cross-site script the user and so on here. But you're kind of limited to that context and we'll look at a local zone reader in the second of a real world vulnerability there. But in the remote zone if you just pulled in this RSS story and put it into the reader without doing any validation then that code could execute. And in this example here it's just stealing their cookie and sending it to my cookiemonster.cgi. Again it just comes back to input validation essentially. Validate that before you use it. And that's one of the things we'll look at later on is fixing security vulnerabilities doesn't have to be particularly complex in my opinion and we'll look at what I mean on that a little bit later on. So the local zone risks this is where we have kind of a reader installed on the desktop. And what that can give an attacker is access to read and write content from the file system. You'll be able to use things like ActiveX components to do a lot of different interesting things. And we'll again see a vulnerability in a second where someone was able to execute any Perl code he wanted on your computer just through injecting and malicious feed. Basically with these local zone readers what a lot of them do is they pull down the feed, write it to a HTML file locally and when you want to view that feed you click on it, it takes it out, puts it in the browser away you go. And when you're using those readers you're in the local context so if a vulnerability exists there then you can read and potentially write from the file system. So an example here is if I injected that into a feed and you can belong in your local reader and try to view it then what it's essentially doing is grabbing a file called secrets.txt using one of those ActiveX components to allow me to take that data out to my filemonster.cgi Now obviously when a user clicks on this you'll get an ActiveX popup saying do you want to allow this? Nine times out of ten the user just thinks it's asking do you want me to go to that website for you to get your news. They'll click yes and you can steal secrets.txt. So a real world vulnerability here in a local zone reader called YASA. Basically part of this application was called GUI.pm. Now when this presentation goes up online I've got all the code for GUI.pm in the notes if you want to step through it and see the vulnerability for yourself but basically what that did was it took in the URL and when you wanted to view it it put it into an exec statement and launched the browser without doing any validation on the URL. So what the researcher figured out was that fine well I'll exploit that then. So he was passing in the link putting this semicolon at the end and doing a purl minus e and well whatever he wanted at the end there really. So again there's nothing really complicated about that attack but again it just shows lack of validation for example allows him to do essentially whatever he wanted to do with that purl on the system. So how can these attacks get worse? Well I think if you could find a vulnerability in a widely used site and a widely used reader so I'd know something like the BBC news site and a popular reader. I'm not really up on what's popular in RSS readers but Google Reader for example. If you could find an exploit in both of those so you could inject malicious code into the BBC site which then exploits the floor and all the Google Reader users. You could have wide scale exploitation of users and whilst you're down on the client side in particular you can do a lot of things like data theft, port scanning and so on. If you can find the vulnerability as you saw with the YASA vulnerability there you're only in that case limited by your purl skills really. So mash up and widgets and kind of where I say widgets here that means that could be regarded as a widget, you know, Facebook applications things you put on net-vibe sites, page flakes, all of those types of things. I couldn't find a common term for it so I just called it a widget for now. So really kind of mash ups, mash ups sites and widget sites I guess are kind of a good example of Web 2 O site so a mash up site will pull in data from different sources to give you one single output and a widget site is essentially a blank canvas site for a user. They can come along and use something like iGoogle and build the web page that they want to see first thing every morning. So we'll look at two examples in a second but I found this site for a mash up that I thought was actually quite interesting. What this site does is it takes in news feeds I don't know where they get them from but Reuters in this case and it's looking there and it's saying that story has come from London so I'll take you to London on Google Maps. A simple example but we see a lot of similar types of sites that out there where they take something and show it to you on a Google map. The problem is and like I said Douglas Crockford said that a mash up is essentially a self-inflicted cross-site script and attack but we're pulling multiple inputs and giving it to you in one output as a user. Now we're pulling that data from multiple sources and again if you don't validate that and just push it straight out there into one place for the user then you can exploit the user. If you think of maybe a similar example to the one we just looked at maybe a photo website where you take your photos and you put a location tag in there saying where you took the picture now if someone comes along and he wants to map your photos to Google Maps then you might have to provide your photo site log on details to him. Now normally if you go to your photo site it's probably SSL and so on and you have you're comfortable with the fact that your credentials are probably protected in transit but how do you know that the mash up site that essentially that man in the middle how is he handling that data for you? Is he taking a copy of it from himself? Is he just sending over HTTP instead of SSL and I guess whilst I'm speaking at DEF CON probably everyone's thinking well SSL is not that great either but the point is if he's not protecting it in transit then you can lose that data. Mash ups by default by their design they have to have that cross-domain access so again if we were still relying on same origin policy it's kind of goodbye to those types of protections anyway now. And then ultimately the mash up site is the middle man and you have to decide do you trust the mash up site itself. On the example before I probably trust Reuters, I probably trust Google Maps but the output I'm getting is strictly speaking not from either though it's coming from the mash up middle man site itself. So there's the potential for maybe if you have a housing site for example and people come and look at that, look at on Google Maps and say oh I want to go to an area with a lower area of crime now how did you know that the mash up site the middle man there isn't trying to sell you his house is editing that data from the way through to you and saying yeah my area is in the lowest crime area by my house from me for an inflated price. And it really comes back to again you might trust the individual sources of data but you're not getting it from those, you're getting your output from that middle man. From a widget point of view I've used iGoogle here but you can see it's essentially a way of pulling different little applications or bits of code or however you want to call it give you that customised kind of page so you know giving you access to your emails, stock prices, news, calendar and so on on a single page. So again it's really just multiple applications like I said different components. The problem can come though is if you have a shared DOM model between all of those widgets. So if I have my security ninja widget up here and you've got your stock price and your email widget down here and we're in the same DOM then my widget can potentially read your emails or make stock trades on your behalf because whilst they're all within that same DOM I can also access any of the document dot whatever elements from my security ninja widget so for your cookie or even doing things like key login, stealing data as I said from your Gmail widget. And I think more importantly more important than that previous point is that these widgets are developed or can be developed and uploaded by literally anyone and anyone could include malicious users. Now there's not a sign on iGoogle saying yeah this is a malicious widget don't install it. That sounds to you as an end user. And I've got an example of a Facebook application I want to look at in a minute but what Facebook saying their terms and conditions is basically we're not going to review any of that if there are security problems with any of these applications it's down to the users themselves to report that to us. So again you install these very much at your own risk. So in Facebook there was an application called the secret crush application and basically you got a message pop up saying someone's got a secret crush on you. Do you want to go and find out who it is? If you want to go and find out who it is click here. Oh surprisingly you have to install this application as well to find that out. You install it and then an iFrame pops up afterwards. Now this iFrame wasn't pushing malicious data directly itself. Basically what it was saying well now you've got your Facebook application do you want to install this other thing from us as well on your desktop. And the iFrame was being served up by a company called Zango who are quite a well known spyware company. So if you install that on your desktop you've got spyware down there. So really like I said it pumps you to install spyware they managed to get that on 4% of all the Facebook profiles of 4% 250 million users. And probably at the end of the day none of those users really loved you. Only Zango probably did. That's not really a good place to be. I'm going to have to fly through these last few now but next up information leakage. Really what we're talking about here is if your application crashes or someone does a SQL injection attack you don't spit out internal information back to the user. So a simple example here. We've got a URL I throw and user columns equals 2 on the end trying to do a bit of SQL injection attack. We don't handle the error properly it spits out this internal SQL error message back to me. So yeah real simple example there. What can make this worse in Web 2.0? Well we have the idea of publishing things like wizard files. And what a wizard file is is it essentially defines how and where you can access web services. There's a lot of information in there that makes it easy to people to come and use your web service. It also makes life easier when I want to come and hack your web service as well. We're also doing a lot of kind of business logic validation storage of data down on the client side as well. And again we're going to look at two quick examples here. So my Google hacking skills not really fantastic and I don't think I'm going to replace Johnny IHAC stuff yet but we're doing a file type wizard search. You can just go and look at these wizard files and you can see people straight away here saying yeah here's the technology I use in the back end to create these files. Again not going to bring the house down by themselves but if I'm trying to fingerprint your infrastructure and find out what you're doing it's a little bit of a help there. And this one here also made me laugh a bit as well. Now I don't have to try and figure out how you're validating my data because you're telling me up front. So you're telling me I'm going to take your email address. This is the amount of character space you've got to play with and here's the pattern I'm going to match that against as well. So I don't have to bang my head away on the keyboard I can just go and grab your wizard file and find that out for myself. Another quick one here. If we're doing validation of data on a client side always back it up server side and never assume if you're storing sensitive data on the client side that it's going to be safe. So the Macworld conference found that out the hard way in 2007. Basically in the client side javascript they had an array of hashes and what was happening here is when you went to buy a pass for the conference there was a special codes field. When you put anything in that special codes field it checked it against these values. So the researcher looked at it and thought well okay let me see if I can brute force one of those values. You brute force one of them in like 10 seconds and got a $2,000 platinum pass to the conference. When there's money involved that kind of money don't do silly things like that. I think they got caught out the following year again by the same research with something very similar as well. So yeah it's not a good idea. Authentication and authorization flaws really making sure that whoever is using their application is who they say they are and not access and things they shouldn't do. So with authentication and authorization we're looking at things like making sure that passwords have maximum age, reasonable lens. If we use things like capture systems make sure it's not just there to look pretty that it's actually a useful capture system. I was using a website back home before I came out the other day and they had four numbers in the capture and they had two little red lines, one above the numbers and one underneath the number. It's not really obscure in the capture at all. So if you're going to use it make sure you use a decent one. It's not easy to get right. Microsoft, Google, Yahoo they all push capture systems out there that have been broken. So if you're going to put that out there make sure it actually does something for you. From a session management point of view make sure your IDs have sufficient entropy so every character is random enough. Don't have predictable session IDs. Don't reuse session IDs and so on. The floor I found in Facebook earlier this year which allowed me to bypass the prevention of security mechanisms so they had on access in people's picture albums. So what they found out is they had a very predictable URL to access photo albums. So the URL just had three parameters. It had an album ID, a user ID and an L equals value and the L equals value was the only unique value in some instances. So everyone's profile pictures album always had an album ID of minus three so I don't have to guess that. The user ID value, I don't have to be your friend or anything to get that and just do a search for you in Facebook hover my mouse over the ad friend link and I can just see your user ID so I'll pop that in there so again I don't have to try and brute force that. So I just needed to brute force the L equals value. They used five characters A to F, 0 to 9. It didn't take the burp suite very long to brute force those for me. If you go to my blog you'll see that they did fix it but they fixed it very badly so the example I'm going to show you in the burp suite now would still apply. It would just take a little bit longer. So really what I did is I loaded the URL up into burp suite. I'm sorry the pictures were a little bit fuzzy but like I said if you go to my blog there's a full write up on the Facebook issue there. The two red values is basically I'm saying brute force those two it went away brute force them. Found a genuine URL for me I threw that into the browser and I could access Bobby Tables photos I'm not logged in, I'm not his friend, anything like that. So again it worked for different albums and so on as well but you had to brute force the album ID value and so on. But as I said if you go to my blog search for Facebook it'll be all up there. What makes it worse in Web 2.0? If we use capture systems that don't provide actually any increase in security then they might as well not be there. More access points in Web 2.0 makes it more difficult to identify weaknesses. Using things like single sign-on your Google account one using their password for loads of sites. Its selling point is also its biggest security issue in my eyes. And then growth in some of those other attacks like cross-site scripting for example. You might have the most random longest, strongest session ID in the world. If you've got a cross-site script and a vulnerability they can just grab that anyway and it doesn't really matter. Running out of time here guys but insecure storage and communications of data really not encrypting data when you're storing it or transmitting it using weak protection mechanisms and so on. Those types of things to what I'm talking about here. What makes this worse in Web 2.0? More data in more places including the client side. We saw that with the Macworld vulnerability before. If you can't be confident about securing it don't put it in that location is pretty much the answer. And when you mix secure and insecure content on a single page the insecure content can undermine the secure content security. There's a talk by Sam Bowne and I think Robert Hansen as well at three o'clock today. I think that's what they're talking about so go along and look at that. Kind of what makes my job harder Web 2.0 more code and the applications are largely more complex has to be generally more than one language as well. So people are using the best language for the job. So JavaScript down on the client side, PHP or whatever on the server side. Just little differences between languages. Even right down to if you look at your regular expressions you use for input and output validation. Different languages have slightly different formats or syntaxes for their regular expressions. So it's more of just getting all those little bits right between different languages. The dynamic nature of the pages themselves in Web 2.0 a single page could have many different representations of that page because we create them dynamically with things like manipulation of the DOM. It's difficult to make sure that you've tested every type of page A for example. And then the increased amount of input points makes it more difficult to make sure you're validating every input that comes in. How can you prevent these vulnerabilities? One of the approaches that I take and if you want more in-depth information on these principles. If you go to my blog I spoke about them at Security B Sides on Thursday so there's a whole PowerPoint up there for that. But really what I take the idea that I try and push is not to try and prevent specific vulnerabilities but just develop securely and prevention of loads of vulnerabilities will come out of that. So what I mean by that is the secure development principles, input and output validation. Make sure you've got error handling, strong authentication and authorization, session management, secure communications, secure storage and secure resource access. As I said if you go and grab that other presentation there's a lot more information on these. And then just visually here to finish off secure development doesn't happen by accident. You need to plan it right at the start, have it in your requirements and design documents, do things like threat modeling, educate your developers, don't just assume that you're going to be able to develop securely, educate them so they can build security into the code, make it part of the application's DNA. Think of it as you make it part of its DNA instead of trying to put a code around it at the end because it will fail if you try and do that. Get someone independent from yourself to review the code and then finally try and hack it yourselves before it goes live. So thank you very much.