 Thank you all for coming. I am David Thiel. This is Alex Stamos and Justine Osborn. We're consultants with ISAC partners and are here to talk a little bit about some new web application frameworks that move web applications a lot more onto the desktop and give them a lot more power than you're used to. So there are a bunch of different vendors and frameworks that we have to get through and a limited amount of time. I'm going to go pretty quick through the introduction here. But aria is a term that was invented to describe applications that behave a little bit more like desktop apps than a regular web application. They are all fairly different, but there are some things that they have in common. They tend to make heavy use of AJAX type calls, so asynchronous updates to pages. They introduce a lot of new local storage mechanisms, including DOM storage, and we'll talk about later some SQL databases. They tend to lean towards having an offline mode so that you can sync up your web mail or something like that and go onto a plane and still continue to use a web application or one of these apps to continue to work just like it were a desktop app. Some of them break out of the browser entirely. Some of them utilize existing browsers, and others are basically like installing a new little mini web browser on your machine. They also have increased privilege in general over what a normal web application has. They're able to store data locally. They can open their own sockets. They can read and write the files. It's essentially a way to turn web apps into full-fledged desktop apps. Basically, everybody started with desktop applications. They moved all of their applications into web browsers and decided it wasn't a very good idea, and I guess so now we move them back onto the desktop, and this is progress. The reasons why you would want to use one of these applications, it's becoming more sexy than regular Web 2.0 stuff. It also does give you a little bit of a benefit in terms of responsiveness. You can have large local data stores locally and cache them and use those. We talked about desktop integration. You can also write these entirely in HTML, JavaScript, Flash, things that web application developers are all familiar with. You don't really have to write a lot of new code, and it's all pretty easy. On the good side of things, it means that people that only have experience writing web applications and web content can write full desktop apps, and if they have good ideas, then we can get cooler applications. But it's potentially not that great of a thing because there's a fairly low barrier to entry, and the amount of privilege that these applications have is increased a fair bit over your traditional web browser app. These are the ones we're going to look at. There are these five major vendors that are all competing for the next big API and way to handle these type of applications, and Alex will start off with Adobe Air. Thanks, Dave. Adobe Air, we have these nice little graphics, which it turns out would take 12 seconds in PowerPoint and took David about two days in La Tech. Just as a quick comparison of how full-fledged the feature set is for each of these different frameworks. As you can see, everything's checked here because Adobe Air can do just about anything. Adobe Air is, while it's called a rich internet application framework, sometimes by Adobe and often in the press, it really is more of a, actually, totally is a full-feature desktop runtime. You should consider it kind of like .NET or Java or any kind of other cross-platform runtime that has the full-fledged run of the desktop to do anything the heck it wants. It's cross-browser and cross-platform. Right now, they've released it for OS X in Windows, but Pellis, do you want to wave to everybody? Pellis will leave from Adobe. We'll take your request for your favorite open-source operating system and prioritize if they'll get right on the NetBSD development real soon. You can make these applications in multiple different environments. You can use Adobe Flex or Adobe Flash, which are commercial products that a lot of graphic designers and web designers are already familiar with. But you can also make these applications with free tools, just writing text, HTML and JavaScript and using the compiler that you can get for free from Adobe. In that case, the basic system here, the basic unit here is the flash Swift that runs within the flash virtual machine. So in the HTML and JavaScript case, that gets compiled within a Swift that is provided by Adobe, a container Swift that then you don't have to write yourself, but then they expose lots of cool functionality through JavaScript so that you can do more things than you can normally do in HTML and JavaScript. This is much more intended to be more powerful than a general re-application. There's no sandbox, apps run with the full power of the user. So because this is a desktop application, shouldn't we just write it off as if it's malicious, that's fine, if it's not, that's fine, it's all up to the user? Not really, right? It's not just like a normal, say, Win32 program on a desktop. The power of air is the I in Rhea. It's the internet connectivity part. It is very... Rhea, air apps are very easy to launch. It's an optional thing for the developer, but it's very easy to make it so that air applications can be launched by web browsers, by sites, and I think that's the way they're normally going to be used, so that if you go to, say, eBay, eBay has their own air application, one day eBay is probably going to turn it on, so if you go to eBay and you have the app turned on, that they launch the Rhea application so you can get the richer interface than the web interface. So they can be invoked by browsers. They have a lot of native mechanisms for loading external content. If you're writing a Win32 program in C++, you have to do a lot of work to download, say, a Flash Swift file and play a movie, right? That's one line of code or two lines of code in ActionScript and Adobe Air. So it's very easy for developers to bring down content from untrusted places and run it locally within this desktop application and it's highly likely that it's going to happen, right? It would be really stupid to go just write a full desktop app that has no internet connectivity with air. It's not the thing that you write the next competitor to office in. It's a thing that you write that has tight internet integration and lots of media capability. So really it's probably better to think of Adobe Air like ActiveX or fulltrust.net applications. The code runs as full privileges and there is some code prevention and sandboxing techniques there. But like ActiveX, once it's installed, it can do anything the heck it wants. Fortunately, Adobe seems to have learned a couple things from ActiveX and we'll talk about that. So Air applications are identified by two things. There's an app ID and a publisher ID. The publisher ID is a big, long, entropic looking string that is calculated by the person's information that they add into a certificate and then the public key of a certificate that is generated for each developer. The app ID is just a string that is decided by that developer. Air applications can't be launched directly from you can't just use an object tag or call them from JavaScript like an ActiveX control. You have to launch them from inside of a flash file itself. So to launch an Air application, you load up a flash file, just a normal jailed Swift and then within that flash file, they pull down Air.swift. Is Adobe's recommended the way of doing it, which is a flash file that now adds more functionality to your local Flash9 instance. Unfortunately, there's no secure way of doing this. You can't do HTTPS here because it turns out to be akamized. If you want to do it securely, you should copy Air.swift to your local site and then change this URL to do HTTPS to your local site. Once that those classes are now defined within your execution environment, your Flash execution environment, you can then check to see if an application is installed and get its version. This means once you have Air apps installed, any site you go to can find out what Air apps you have installed, which is fine for some Air apps. If you have the My Little Pony MMORG written in Adobe Air, perhaps that's the kind of thing that you don't want to expose. There's no way that you can prevent malicious flash applets from finding out what Air apps you have installed and exactly what version. And once we know, hey, it's installed, it's a pretty simple to just launch it, calling the new function called launch application, giving it the app ID, the pub ID, and then arguments. That's an array of arguments of objects that get passed to it. So this can be passed from a non-trusted Flash.swift into a trusted Adobe Air application. By default, the code that runs in an Air application runs with full writes. They've added a bunch of classes, JavaScript or ActionScript, depending on what you're using to write your Air application in, to do a bunch of dangerous stuff, like talk to files locally and install and program files. You can write stuff over, Windows, System32 and such. With the existing capabilities in Air 1.1, it is possible to make a local system run native code into backdoor and operating system. There are rumors on blogs that talk about it that Adobe will eventually add more things like shell execute and stuff. There's no actual security downside there. You already have full control. It will just make it maybe a little bit easier for people. You don't actually have a code access security model, like .NET or Java, where you have method per method or class by class control over what an application can call. Instead, they've created five predefined sandboxes. The application sandbox is the default sandbox that your application boots up in. You can do anything you want. There's the remote sandbox, which is if you pull stuff down from the internet, like a switch from the internet, or you open up an iframe to an HTML page on the internet, then that's going to, by default, run in the remote sandbox. And there's three others that if we had multiple hours we could talk about, but you guys probably don't care about. Kind of intermediate ones. To, when you load that external data, it automatically goes into the remote sandbox. An important part of their security model is that stuff that runs in the application sandbox, the local code that's doing all the dangerous stuff, should not be able to do just-in-time execution. It shouldn't be able to pull code down and then install it. Flash used to have the ability that you could take a byte string and create a flash class out of it and call it. You can't do that. You can't run the JavaScript eval command, for example. You can't have a script tag that does a cross-domain source. So they've worked really hard to find all the things that allow you to get commands from the internet and not allow them in the application sandbox. On the other side, there's the remote sandbox. The remote sandbox can't do dangerous stuff, but it can do things like evals and pull down swifts from remote that run locally and pull down JavaScript remotely and can do cross-domain XMLHP requests to pay on some things. This is probably a sufficient place for most developers to write their code. Unfortunately, though, they're going to be running the application sandbox by default. So these are some reasonable security protections that Adobe has probably worked very hard to put in. Obviously, because they're reasonable security protections, web developers are going to work really hard to circumvent them, which is the history of how this kind of stuff works. So one thing they could do is look for mistakes Adobe made in the classification of methods that are dangerous or not dangerous. That's not easy. We've looked a little bit. It seems like they've done a reasonable job of the stuff that can't run the application sandbox. That's dynamic code and classifying the dangerous stuff that can't run the remote sandbox. But better yet, they provide a mechanism that allows you to move information back and forth between these sandboxes. It's called the sandbox bridge. Basically, the way it works is, say I have an application that runs in the application sandbox, it can do anything the heck it wants, and it wants to load up an iframe, and then that iframe is going to be untrusted code from the internet, but it has to expose some kind of functionality to that untrusted code. You create an object, like here we call the high-right stuff object. We give it a method called write to file, and we put a bunch of dangerous stuff in there, and it takes a couple of arguments, and then we attach that object to what's called the parent sandbox bridge, which already exists, and then once we've attached the parent sandbox bridge, we call and we say here's an iframe, pull down some dangerous stuff, and then the code in the iframe, say JavaScript, say okay, parent sandbox bridge, thank you for giving me that function, the dangerous function, I'm going to use it. It's kind of like setting a set UID bit on a method. If this is a variable, it's passed by copying, it's not passed by reference, but obviously it has to be some kind of passing by reference if it's a function like this, because it does run with the permissions of the parent. So in this example, this was a very bad move, right? In this case, the developer created a function that can take an arbitrary file name and arbitrary content, and then write it to the hard drive, and then expose it to the untrusted code running in the iframe. And so in this case, they have, with only a couple lines of code, the web developer who are the air developer, they're not web developers anymore, right now they're empowered to be desktop developers. So the desktop developer that doesn't know how to use anything but HTML and JavaScript has gone and ruined the entire Adobe sandbox model. Adobe has to provide some kind of way but it looks like it is going to be pretty easy for people to shoot themselves in the foot. Air requires Flash 9. Air itself is an add-on to Flash that the first time you load an Air app, Adobe provides sample code called, I think, Badge.swift that will automatically have the Air methods loaded up and it gives you this little pop-up, do you want to install Adobe Air? No real security warnings or anything. This actually isn't like too dangerous a thing. There's no security in installs. Once the Air runtime is installed in Flash, Air applications can be installed. They can be bundled as .air files which are binaries that contain a bunch of swifts in an XML file and stuff like that as zip files. They can also be installed from a web page. If you have a Swift, it can call the install application function. That pops a little thing that says do you want to open this file or save it? After that you get a prompt like this. The Oracle Air application has to be signed by either a trusted root cert and they've got three CAs I believe that can issue those certs or they have to be signed by a self-signed cert. So this is what you get if it comes from a trusted cert. If you paid more than $120, there would be projectors here that could actually show you this text. But I'll read it for you. It says publisher which is a publisher name that's pulled from the certificate. This is an application name that is controlled by the bad guy so you can put not necessarily the bad guy, the Adobe Air developer. The Air developer can put anything they want in there. It says system access unrestricted. And then this little green icon says verified and then the little red icon says system access unrestricted. The application may access your file system in the internet which may put your computer at risk. While technically accurate, this is perhaps not a strong enough warning but by the way, if this is malicious, it can do whatever the heck it wants to your desktop. If it is unsigned, and also the default selection is installed so if you hit space or enter, you're going to automatically install it. If you do a self-signed certificate they don't show the publisher, they say unknown, but they do still publish up the application name. In this case, it's a string of Chinese characters I can't read, and this is an application I downloaded from Adobe.com published apparently by a Chinese person and the publisher identity can't be determined and it still has unrestricted access. As of right now, there's no way to turn off the bottom that says unrestricted access because there's no version of air that doesn't run with full access. So that always says red unrestricted. This kind of looks like pre-internet Explorer 7 ActiveX controls. Just like Microsoft, Adobe has decided we're going to give people the information necessary to make an intelligent decision. But unfortunately, the level of skill needed to make the intelligent decision includes understanding the public private key cryptography of how the flash virtual machine works and whether or not Adobe Air is a desktop run time. So for all you guys now, you can make that decision intelligently. If we give this talk another, something like 120 million times then we should cover the internet using populous and everybody will be able to make that correctly. But for the most part, just like with ActiveX giving people the correct information might not be enough. The ActiveX gave that right information and their legacy became malware that people would click yes to anything because they couldn't make that intelligent decision. So this kind of scary thing is that these days the flash virtual machine is much more popular than internet Explorer actually has ever been. They have a more dominant position in the internet market than internet Explorer ever had and so it might be a much better way to seed malware. So our suggestions changing the default action self-signed certificate adding a countdown timer at least in the self-signed section so that people have to read the warning. There is a registry key to turn off self-signed certificate support. Right now, it's allowed by default. There are reasonable reasons why you'd want to support self-signed certificates but I don't think it's a reasonable thing to have turned on by default for most consumers so flipping it. And then I don't think Adobe is utilizing self-signed error binaries from their own site from Adobe.com. It's probably better for Adobe to enforce people getting real certificates and perhaps doing a couple of sanity checks on the Air Apps before they come through. Right now you can upload any Air App to Adobe.com. It's going to be exposed to a lot of people. It might be a very good way to seed malware with Adobe looking to give a grant of imprimsure that this is a reasonable thing. We also think that there's probably some room between totally jailed air and completely free loose I'm sorry, totally jailed flash and completely free loose air. Most of the applications that are probably going to want to use air don't need to install a root kit. Right? That's not a function that the eBay online store really needs. Well, maybe they think they need it but I don't think that for their business model as of now they're going to need that kind of functionality. So perhaps in Air 2 or Air 3 we will see a middle ground solution here where you can install an Air application that can't do anything willy-nilly. Okay, so we'll have questions at the end because we're going to run out of time but for now we'll turn it over to Justine. Talk about Silverlight. So I'm just going to give a brief overview of Silverlight. Silverlight is a browser plugin comparable in functionality to Flash. It claims to be cross-platform but currently Linux support is left as an exercise to the community. It supports a subset of the .NET framework and there's two versions. Silverlight 1 has been finally released and Silverlight 2 is in the beta version. So both Silverlight 1 and Silverlight 2 use XAML to render DUI. So XAML stands for the version market language and Silverlight 1 uses JavaScript for dynamic content. Silverlight 2 introduces the core CLR which is a slimmed down version of the .NET CLR for dynamic content. So here's an example of some XAML markup. So this is a this is language similar to HTML. You can create little widgets like a slider. It's very simple and easy for designer, intuitive for designers to pick up. So this is what that markup renders in Silverlight. Silverlight security model is based on the .NET CLR security model. So code access security. Very briefly code access security based on code identity. So your code gets different privileges depending on where it's from. So if it's from the internet it's going to have less privileges. So Silverlight has simplified classic code access security so that the developer can only write transparent code and then they can call into security, they can call into critical code with security safe critical APIs which Microsoft writes and they are signed with the Microsoft public key. So that's how the sandbox works. So here's an example of what I'm talking about. I can't in my Silverlight application call file.create because that's critical code. The second example will succeed because I'm calling from a safe critical API which does stuff like input validation as is shown in the example the third example which will fail because it's trying to do something nasty like talk to the modem. So isolated storage is an example of one of the safe critical APIs and some of the power that Silverlight has access to the local system and you can deny local storage so that's a good thing to know. And network sockets is another way that Silverlight allows the browser plugin to access the local system and it requires a client access policy. So I'll talk a little bit about the cross domain and Silverlight. So Silverlight honors the same cross domain policy as Flash so it will accept a cross domain.xml file. Silverlight by default should only be able to call back to its domain of origin but you can configure cross domain access with these policy files and client access policy is Silverlight's version of the cross domain.xml. One of the interesting things that Silverlight has that Flash doesn't is the ability to turn off access to the hosting DOM so you can embed Silverlight applications in the DOM and disallow them from I mean sorry in a web page and disallow them from accessing the DOM. So the big deal here is that the attack surface is really in the safe critical APIs and that's really Microsoft's job to to maintain so that offers some control with patching and what not and then the other attack service is really denial of service attacks against the user because Silverlight has access to the local system Silverlight applications don't have to exit it's up to the developer to implement that functionality so really brief overview but there's some fun stuff to play with here and a lot more work to be done so I'll pass it over to David. So the frameworks that we've talked about so far have been kind of ways to write full-fledged desktop applications in the case of Air it's totally outside of the browser with some ways to interact with it some of the frameworks that we have coming up here including Google Gears, Yahoo Browser Plus and Mozilla Prism are all more based around the browser but give extra capabilities so you can see here that Gears doesn't have a whole lot that it can do it does allow for running disconnected and the main goal of Gears is to cache content locally and make it so a web can be a local app so what the things that Gears consists of there's an API for syncing data between your local machine and site there's a SQLite instance locally that actually stores the data for that syncing there's also a locally running application server so you've got a browser plugin that actually if you're disconnected it'll cache content and serve it back up to you from a local web server so the other cool thing is that there are worker pools in Gears and these are a method for if you have really intensive JavaScript calculations to offload them to be processed by something else rather than actually running inside the browser where you might lock the UI or diminish user experience so for the most part the mechanisms that are in Gears just utilize same origin as you know as a security precaution they do give the ability to use parameterized SQL statements for accessing local database stores and they do prompt for install it's not a really awesome prompt and doesn't give users a lot of information because in Gears 0.3 which is still the current version I believe they introduce the ability for developers to basically have the security warning to look however they want it to so here is a pretty trivial example if you're actually if you saw the Jafar talk it turns out that there at least used to be a way to actually spoof the real URL but what you have here is the friendly name up top and if you just make the friendly name look like a legitimate site you can actually customize the icon here so that it looks like a lock which makes people want to click yes on things and you can try and convince the user in whatever way possible to actually allow this it's not any information as to what could go wrong when you're accepting this kind of prompt and I'll kind of get into what can actually go wrong a bit here suffice it to say that allowing developers to customize security prompts is not a great idea but so with worker pools one of the neat things about worker pools because they don't lock up the UI or make your browser run slow you can actually use them for things that would otherwise trigger say firefox's you know runaway script detection where it says hey this page is taking a really long time to respond do you want to let it keep going or not because it's so easy to get somebody to actually allow a site to use gears you can actually use this to do things like push a bunch of hashes down to these machines and do hash I mean javascript is not the fastest way to crack hashes but if you have an army of people that are all coming to your website and clicking yes and allowing you to use gears you can actually run this stuff in the background they go up and surf elsewhere you can have it serve up the answers when it gets them and it turns out that this actually works reasonably well so the components of gears are pretty simple yahoo browser plus kind of goes in a weird direction where the idea of browser plus is making it so that developers rather than writing a you know using a little framework for local data storage or other mechanisms like that it basically makes it really easy to write your own modular browser plugins so because nobody understands NPAPI and very few browser plugins exist yahoo decided a way to make powerful web applications would be to write something that would allow people to just push down new browser plugins that run with full privilege so it's there has been some attempts at putting security into this framework their inspiration for a good security model has been that of browser developers which for something that actually allows you to run desktop applications is there could probably be a stronger model to follow so you actually you initialize this over an insecure connection back to yahoo it's another place where who knows because it's Akamai or something you can't do it over SSL so the first time you actually install it you don't even have to restart your browser it installs this plugin and starts handling this stuff and it'll push down on demand components that are necessary for the web application a couple of things that are included are a locally running version of image magic to do image transforms which has traditionally not been a terribly bug free code there's a little sample app for uploading stuff to Flickr notifications for Growl and Snarl to kind of poke into the OS notification framework and an embedded Ruby interpreter so this actually allows you to write further browser plugins in Ruby so it's kind of this mashup of ancient plugin technology with new sexy slow interpreted languages but so these of course all run on the local machine with full user privilege it's it's worse than ActiveX is near as I can tell the Ruby version that was shipping up until a week or two ago was actually the same version that some people might have heard about that had really trivial overflows in both arrays and strings so precautions to developers as long as you don't actually develop any applications using arrays or strings you're perfectly safe so it's not something that was actually hanging out there for a really long time and that's a really old version of Ruby so it doesn't seem like there's been a lot of focus on keeping this stuff up to date it's in a preview phase and part of the reason for that is because they're trying to figure out how they can do this without making everything entirely insecure and I can't really see a way that that's going to happen right now there is a framework for actually signing these modules but they also accept calls from outside sources you can get any kind of code execution in these modules you can actually clobber the white list that says where you can load browser plus plugins from or correlates and you can also change the verification procedures all of these can clobber each other there's no protections against any of them so it's not that great of an idea so this might be able to be turned into something usable from a security perspective but in general as it stands right now there's with no sandboxing at all it would probably be a really easy way to install malware so actually probably my favorite of these frameworks are the ones that try and use a standards-based approach rather than trying to invent new APIs that aren't cross-platform and making people install them prism is actually pretty simple in concept what it is is just a way to encapsulate a website into kind of a chrome-less standalone browser and they set up their own little profiles and they're locked to one site if you click on links to another site it'll actually open in a browser just like if you're in an email application it just passes it to the browser it doesn't try and follow that stuff around which is a good design and there's no, you can't even override SSL certificate failures which is also a pretty decent idea they're really trivial to make in their most basic form all they need is an I&I file that says where to go some CSS layout stuff some JavaScript rules and things like that there's a couple of prism apps running together you can see that they'll sit around in the task bar and you can they don't have any location bars or anything like that you can write something that looks like a full app like Thunderbird or something and it's not even necessarily apparent that it's a web app the place where prism falls down is that the actual JavaScript UI that you install has full XP com scripting privileges so this is the language that people write Firefox add-ons in so anything that you can think of a Firefox add-in that it can do you can basically do in one of these web app bundles which is a little bit of overkill since you don't really need to change a whole lot in these bundles it's a pretty simple idea so with Firefox add-ons you have a simple way for people to there's a signing mechanism there's an install prompt, there's a counter there's a fairly good explanation to the users that this is not necessarily safe code in prism what you get is what looks like a bookmark dialog and you check a couple of boxes if you want it to behave differently than the default you say where you want it to go no warnings or anything so it turns out that you can actually use this XP com scripting privilege to do things like right now that people just host their web app bundles on a remote site and they say hey I've made a bundle for such and such site and encapsulating that go ahead and install it it turns out you can do things like you know if you had a webmail.com bundle you can just do things like change people's proxy configuration settings to go through a server of your own or relay content to other places it's really a lot more functionality than anybody would really need to add here so the idea of prism is actually I think pretty sound the XP com scripting privileges should really go away especially since they're actually starting to push this I think it's one of the featured add-ons for Firefox that they want people to install outside of the prism framework there's actually functionality in HTML5 and new browsers like in WebKit and Firefox that allow you to do a lot of re-typed stuff cross-platform without having to lock people into a proprietary solution you may have heard of DOM storage a new parts of it are a new mechanism that were introduced in Firefox and WebKit they give you a couple of different mechanisms to store data locally they give you session storage and local storage session storage is just per session local storage is a big 5 meg data store that you can use you can have access to a local SQLite database now through the open database function so you can create your own databases like you were creating a cookie and these are all protected by same origin restrictions but they have a couple of other interesting facets so the reason why DOM storage is introduced you can do local caching you can do user tracking without having to ever prompt the user or let them know that you're doing it you can it gets around the things that web developers don't like about cookies which is that people delete them or they refuse them and they have to write code to say turn cookies off and things like that this gets around a lot of that you have a really big data store and you can load whatever you want into it and like I say it's an excellent tracking mechanism the other thing is that now that SQL databases are running on a local system you have the possibility where normally SQL injection was a server based this was you attacking a server trying to get data off a remote database and if you had for instance cross-site scripting flaws you would use them to try and steal a user's authenticated session login and do stuff as them because you're now storing data locally you actually have the case you have the possibility for SQL injection if you can pass parameters in some frameworks let you parameterize and some just let you want you to write raw SQL but there's also a neat scenario here which is that if you go to a website that has cross-site scripting flaws and you go to your web mail site and you've got some data cached locally in your database you can actually have pre-authentication cross-site scripting flaws that can steal this data and shuffle them off elsewhere so you don't even have to actually wait for people to be logged in anymore to steal or destroy any of the data that they're storing which makes cross-site scripting kind of an interesting attack so there's a couple of things that are specific to Firefox 3 that will go through here real quick up until beta 2 they were still considering pushing cross-site XMLHP requests with no real defining policy in there thankfully it was pulled out before Firefox 3 shipped but as near as I can tell that's still an open issue so if people have any pressure they can exert on Firefox to not do that they should exercise it it also has a global storage mechanism and this kind of highlights part of the problem with some of these frameworks which is that people are... you would think that a standards process would work where people would write a standard and review it and then go implement it in products and that's not how standards work at all what happens is people write a draft standard that's kind of half done and has some ideas they've been kicking around and the technology implementers the browser vendors have been looking at those and that particular feature is kind of neat we're just going to implement it now so that happened with global storage it was then pulled from the HTML5 spec because it wasn't a very good idea it allows you to just use named data stores and with actually pretty small domain restrictions Firefox 2's were particularly bad and of course nobody knew that Firefox 2 had this mechanism and there was no UI to actually let people know that this new storage tracking mechanism had been inserted another thing that's strange with Firefox 3 is that you have a whole ton of data that's not relational in SQLite databases that open up some other interesting attacks there's actually... people are interested there's a lot of stuff that went into Firefox 3 that's really interesting if you go to a page called Firefox 3 for developers there are a whole host of that are many of which can be their own research project support for the extended extensible style sheet language I guess it didn't have enough extension mechanisms in it already so they needed a more extended version there's the NS idle service XP com method which allows for tracking how long users have been at their computer and if they're going away, things like that there's also one of the probably not best ideas that went into Firefox 3 it's not a bad idea what happens is now you can use other websites as protocol handlers so if you're a favorite site for sending email or your email program of choice effectively is Gmail you can go ahead and tell the browser that I would like to use Gmail to handle this instead of spawning Thunderbird or Outlook but the protocol handlers are another place where verification is really weak this is just a very small snippet of code here that asks for a user to say to use their site as a protocol handler so since transmission of mail is something that's good for an attacker to take a look at for snooping on users you can actually just again and I put in your site by IP address the only actual restriction on installing protocol handlers is that the malicious site and the sites that the protocol handler refers to has to be the same which isn't actually a restriction at all so here's what it actually looks like if you try and use a third-party protocol handler in Firefox do you want to allow Yahoo mail something that you don't understand as an application for mail to links and your options are add application or you can kind of close the dialogue but mostly just add the application if you would and this the funny thing here is that when you actually add a protocol handler it'll do things Firefox already actually knows about Yahoo mail and it knows where to send stuff for that and that's the second option here but the actual malicious snippet up there what it does is it actually goes through it follows the link finds the fave icon and decides to use that as the icon for your new protocol handler not only that but in Windows XP it makes it so it's gray on gray so you can't actually there's an IP address under there but you can't tell what it is so what you actually have happen is you get a this more real than the real thing protocol handler that would make people accept choose a malicious one over the real one like hyper real or a simulacra or something so I'm going to go pretty quick through WebKit but suffice it to say that WebKit is actually they were pretty early adopter of some of these local storage mechanisms they've had SQL database support for a while and it's in a lot of stuff it's actually Nokia is the second biggest user of WebKit after Apple because it's based in what's used on the iPhone a lot of people probably don't know that you can do things like use local SQL databases for storage there but it's also an open moco and it's what air uses for its rendering engine so part of the problem with these storage mechanisms other than the fact that you can do tracking with them is that they're all basically capped at 5 megs and they're all per origin origin being the classical thing if you have 10,000 domain names you've got 10,000 origins you can just have them be sub-domains of a main site so you have 15 megs per origin and anybody that's actually got wildcard DNS or a whole bunch of names or is on an internal network can actually fill up your hard drive pretty quickly in a matter of depending on your hard drive capacity it could be 10 minutes to say 10 minutes but you can actually make this stuff grow out of control really quickly that's actually really important if you've got a mobile device because if you've only got 8 gigs of storage and you can take it all out and you're pooling your storage with your actual RAM you can kind of not brick permanently but you can make these devices pretty much unusable there's no way to actually disable these mechanisms that's easily available so there's some sample code if you can pick out the slides afterwards that kind of show how you do this kind of stuff one other little quirk about this kind of stuff is that you can actually insert a bunch of basic 64 encoded data that forensics programs will try and pick up so you can use this to shove tons of arbitrary content inappropriate images or things that people aren't supposed to be in possession of and litter the user's hard drive with while you're doing your little DOS attack and this also works quite well in practice HTML5 is a weird beast I encourage everybody to read the specification there's security so far has not been part of the standard process the only thing that's actually in it is that there's a note that needs to be written someday but the spec is pretty it's pretty much approaching completion as near as I can tell and it's something that should probably go in a little bit earlier than the very end so I'm going to turn it over to Alex to kind of talk about some of the more interesting and ways that you can use these rea-frameworks to attack users and what you can do about them thanks to wrap it up let's go through some of the new kind of attacks that we're facing in the rea-web 3.0 world sorry I said that but to throw it out there some of the new things so attacks of rea-applications against the operating system we have now local storage which as David pointed out there's a lot of privacy and tracking concerns because either UIs don't exist or the UIs for wiping out or turning this stuff off are not integrated with UIs for cookies so just about when people started figuring out how to turn off cookies or clear them appropriately local storage mechanisms that they don't understand we've started to see this with people banks using flash cookies and flashes local storage mechanisms to track their customers and they call that dual authentication that we also have a denial of service risk like he said by using multiple domains to 5 megabytes times infinity is still infinity right so having a limit that they can be used over and over again gives you a denial of service app mechanism from a malware perspective probably Adobe Air is the most concerning here just because it does have as designed full privileges locally although all of these frameworks are adding new huge attack surfaces right the fact that an entire SQL databases embedded in your browser and called callable by malicious JavaScript is huge right because now you have every kind of command that you can do in SQLite you can execute locally and if SQLite has an overflow now you have a very rich broad attack surface and anybody who's ever read the errata on a single oracle patch will understand how difficult it is to write something like a SQL interpreter that is secure and the air situation you're talking about people using the install box and trying to trip people into install it having a malware issue from a web perspective we now have a very interesting issue where cross-site scripting pre-login becomes much more powerful cross-site scripting it gets a webmail app used to only be useful if the person had an active cookie which for a lot of times they would or you'd have to do you'd have to trick the person to log in and then have the cross-site scripting execute afterwards now with local data storage if I can do a referred cross-site scripting I can do it in an invisible iframe they don't have to log in or have a local cookie it can just run and pull all of your cached email out of the local data storage and send it right so pre-authentication cross-site scripting with the local domain storage and local SQL storage for years in html5 is very frightening in ads a lot more power to cross-site scripting attacks that were kind of useless before we now have sql injection in javascript your web app not the database behind it but the javascript that runs to make your web 2.0 app run can have a sql injection vulnerability and that's not a good thing because the people that write the javascript and write the html are not the same people that write the web app and also people that understand what sql injection is in the past so we're talking about a whole new group of generally graphic design kind of people that sit at ritual roasters in san francisco with their macbook airs and their thick glasses and there are lots of piercings that those kinds of people now are going to have to worry about sql injection they've never had to do it before csrf is something interesting from rea apps we can't really cover that too much in the price of prism we have sandbox apps that can affect each other and do all of the nasty xpcom stuff we have xpx browser plus we have modules that are running with full executable locally and as david said things like image magic which has all of these algorithms that are extremely dangerous have had buffer flows in the past we can also chain these frameworks together you can run launch an air application from inside a prism app for example and so there are some concern there so some checklists if you're a rea developer your data stores for local sql or structured data use a parameterized sql if you can although that's not always possible walk your app to your domain some other stuff you guys are bad guys so we'll skip ahead if you're a security professional our recommendations are looking at the attack surface such as the il parser to the new virtual machines embedded html rendering if you're a corporate admin don't let your users install rea frameworks you can use something like group policy objects to do this in active inie in firefox if you're a normal person don't install a rea framework unless you actually need it read the install boxes carefully and get ready for the apocalypse if you're a penetration tester look for dangerous parameters passed into something like an air application on instantiation make sure people are using parameterized sql statements make sure that data stores if possible are using guids for naming conventions to be able to find them look for limits on storage mechanisms make sure people are using ssl with these mechanisms because they're so dangerous if you pull down sql code they can use them over html you now have a much more bigger issue than people like stealing cookies so in conclusion these rea frameworks are very widely different in what they can do in their security models it is extremely likely that using these rea frameworks that web developers are going to introduce all kinds of new very interesting flaws that in web applications as well as things that are supposed to be desktop applications and the web is becoming less standardized which is the whole point this is all about corporate control of which of these companies is going to control the api inside of the browser so breaking standardization is what you have to do if you want to monopolize the browser but from that perspective it's making security a little harder it's making things a lot more dangerous so I don't think we have time for q and a because I'm getting some kind of you're going to die cut cut cut side so we'll step off the stage if you want to ask questions 1.15 for a breakout session if you have questions or comments so thank you for coming