 And what we do is we find and we fully disclose the holes that we find in these web servers. So what kind of holes are these? Okay, these are the kinds of holes. About holes, I don't mean hacking in the ebay and changing the website, but I'm posting up some alternative message. What I mean is gaining access to an arbitrary number of usernames and passwords from the base servers or the hotmail servers. Exciter, Yakumail, things like that. And the way that what we focus on really is not working at the level of networking. Okay, so we work a little bit higher. We work at the level of the application itself. So we're not going in and we're not trying to compromise a firewall. We're not trying to gain a root on the server. We're actually taking advantage of holes that are in the web application layer. So Hypertext Transfer Protocol went above the actual application itself. And we'll see how that's done. Okay, and some of our targets have been, like I say, hotmail, Yakumail, like Osudora, a whole bunch of services powered by iNet address and Excitemail. So yeah, so we're going to spend some time talking about Java, JavaScript, VBScript, Shockwave, and all these client-side technologies, okay? Because the way it's funny, a lot of these large corporations spend a lot of money, a lot of energy, pay a lot of attention to gaining a really secure network. And it turns out that the application itself is inherently insecure. So you don't have to know a bloody thing about networking in order to get in and compromise the system. And frightening enough, you don't actually even need to know a lot about server-side, I mean, client-side programming. A few lines of JavaScript is all it took to gain an arbitrary number of hotmail user names and passwords. Okay, and just a little bit about our resources. So like I say, we're a small group, and everything that we do is pretty well-financed out of our own pocket. We run our stuff off really old boxes, 486s running free BSD. And we lease back-room space from our internet service provider. Our major cost is our internet service provider, which is about $200 a month. We do most of our work from home. So we don't collect any money from the holes that we find. We don't have any form of advertising or sponsorship, and we don't sell a product or a service. So we all have day jobs, and this is sort of what we do when we come home and online. Okay, so the philosophy behind these sort of the exploits that we find, like I say, we find that in order to, when we do find a major hole in a large web service, we find that the best way to get it fixed is basically to fully disclose nature of the problem. That means provide full source and instructions on how it can be done. And also, and this is really helpful for working with the media, actually provide an online working demo so that anybody can go to the site and pop credit for themselves. And, you know, there was a really interesting talk yesterday about a fellow here that was talking about how you can interact with the media. And he was suggesting that you shift the onus to the hacker to educate the media. That's actually the case, and my recommendation is that don't let the media write your story, write your own story, put it up on your own website, and just point them to the website. That's the best way for them to get the fact straight. Okay, anyway, the net result of finding these holes is that they result in a better web-based service. So the whole point of finding these security holes is to improve the service, not to go out and, you know, bring them down by storing thousands of usernames and passwords in a database then writing a program that does some funny stuff. Okay, so in the extroverts we found there's been sort of a funny kind of pattern, a life cycle almost to the extroite. It tends to be the same thing over and over again. When you find a hole, and again I'm focusing on these holes that are accomplished through client-side programming, generally the first thing we do is we warn the web-based service that they do in fact have a major security hole, and it's quite common actually to get ignored or banned or just plain refuted. All three. So the next step, the next thing that we do is we post a working demo on the source code on our website. After that, usually the web community picks up on it. It's in the bug track in the news groups, and the web media picks it up, like .com and news.com and slash . and things like that. And if it generates enough interest, which is usually the case if it's a major uphole, then the paper media picks it up, a local paper or a national paper, something like that, and it starts getting thrown around the papers. And basically once the web media picks it up, the online service itself will have a major reaction and they will quickly try and fix the problem overnight, which is a sort of an uphole patch. There's a major problem and that suddenly the information is posted out there on the web for anyone to see, and the first thing that they want to do is they want to patch the problem as quickly as possible. So generally they will put out a patch that specifically targets the demonstration that's been put online. Without actually, in many cases, solving the underlying problem. So it's not uncommon for them to release a quick fix and then to be able to compromise that again the next day, which is pretty funny. And of course then that results in that we all get rich and famous. But it does result in a better product and we feel much better about ourselves. Okay, so just briefly I'd like to talk about just to sort of set the stage for understanding how can it be so easy to gain access to all this data that's sitting behind ultra-secure firewalls, et cetera. To set the stage, I'm going to have to talk a little bit about HTML and the interaction between a web client and a web server. Okay, so HTML and brief, let's get this over within 22 seconds. Just out of curiosity, how many people here actually have worked in HTML? Oh, the vast majority, okay. And now we're sort of thinking that you're all networking gurus that didn't bother going up that high. Okay, that's cool. Okay, so in that case I really can't make this brief. As we all know, Edit Simplest HTML is a series of tags that's applied to a text document to mark it up so that when it's displayed by a browser and to make a long story short so that the browser will know how to display it, how to format it, what images to display, and things like that. So yeah, the browser reads the tags for information on formatting, creating hyperlinks, displaying images, and that's really what a super simple web page is, right? And it's hard if the web is all about text and images. At least that's what it was originally. And then the web became more complicated than that. All right, suddenly people... Well, actually this is built in from the very beginning, but the web became more complicated because we now had the power to do server-side processing, right? We had the ability to tie the front end into a back end through HTML forms. So that's server-side processing, right? CGI scripting initially. So we could connect the front end to the back end. And then another cool thing came along. Suddenly we found that we could do client-side scripting, right? So using things like JavaScript, Java, Apple, Shopway, Flash, right, and all the stuff that comes in with the plugins, suddenly we had the option to either do processing right in the browser itself, or to transfer all the knowledge or all the data that a user fills out in a form, send that back over to the server, and then have the server do some form of processing and create a follow-up page. Okay, so the link between the front end and the back end. Let's look at that because I want to focus a little bit on the back end, the server-side program. The link between the front end and the back end is an HTML form. What is a form? A form is just a collection of graphical user interface elements, right? So things like text boxes, text fields, radio buttons, check boxes, things like that. That's a form, and it's implemented as an HTML tag, okay? Now the tag, that form tag that makes those graphical user interface elements also provides other information, okay? It also points to, you can see up here, here's an example of a form tag, right? You can see that actually, it has an action attribute there that actually points to the server-side programming that's going to process the form data, right? It also has an attribute called method, which can either be set to post or get that just basically, that basically specifies how the data is going to be transmitted to the server. And here you have some input tags and those actually create the graphical user interface elements themselves, okay? So in a form you have two things. The form allows you to create the graphical user interface elements, and inside those, inside the form, the form holds the data, okay? That the user will be typing in, okay? So if you have a name and password field in a web application, someone types your name and password into a form, that data is a part of the form and can be accessed, as we'll see later, through client-side scripting, okay? It's considered to be a part of the form now, accessible through the document object model, which I'll talk about a bit later. Okay, so anyway, the big picture is that the form ties the front into the back end and it contains the data that people fill in in the form itself. Okay, so people go to the form, they fill out all their information, they fill out their username, they fill out the password, they click the submit button and what happens? All that great data in the form gets packaged up and sent over to the server-side program that is specified here in this action field, right? So it gets sent over to the server-side program. The server-side program takes those name-value pairs, in other words, the data from the form, does something useful, who knows what, and then creates a follow-up page. Okay, we're all familiar with this, I'm not going to belabor the point, but we've all used search engines, right? Many of us have probably used webmail and e-commerce sites. Okay, this is the basic premise behind all that cool stuff, okay? Most of the time, you're actually just sending the data over to a server-side program. So what is the form? The form really constitutes the basis of a web application, right? It's pretty hard to have a web application, a portal-side, or whatever you want to call it, without using forms, without tying the front end to the back end, right? This form will contain user authentication information. In some way, shape, or form, a web application has to keep track of its users, right? It has to keep track of who you are, what are you ordering, what's your credit card number, okay? But the basic user authentication information is quite likely, quite often, passed back and forth between the client and the server, okay? So usually, just by looking at a form and a page, you can pick out a lot of really useful information. So the bottom line is that when you are in a session with a web application, what you don't want is you wouldn't like it if somebody else could see the values inside your form, okay? Except your data, your username, your password, your credit card number is what's sending that form, right? And generally speaking, it would be pretty hard for someone to be able to reach into that form and grab that data out of there because it's on your web page, right? Nobody else has it, just you. Everybody has their own username and password embedded in the form that they get from the web application. So what's the problem? How can there be a security problem? Now, to understand that, we have to have a look at the other side. Let's look at the flip side now. Let's just look at the client side. Let's say we want to do processing, but we don't want to communicate with the server, right? We don't want to send all that data back to the server for processing. We want to do it all in the browser itself. We can do that using client side technologies like JavaScript, VBScript, Shockwave, Flash, Java Applets, okay? So up those, you can sort of break all those client side technologies down into two major groups. In one case, the actual code is sitting right inside the HTML document, okay? So it's right inside script tags, smack right there in the HTML document itself, okay? This is an example of that of JavaScript and VBScript. In the other case, the code that gets, the code is not sitting right in the HTML document, but it's actually sitting in a separate file on the web server. And what the browser does is the browser has to go, fetch that file, download it, execute it, okay? So either the code is directly in the HTML document or it's in a separate document, like a class file if it's Java, right? Okay, so which of these, out of these two categories, which is the most powerful, which presents the biggest threat? Well, we all present a threat we've shown holes with both kinds of client side technologies, but generally speaking, category A is more powerful. Okay, category A has more direct control over the document object model, has more control over being able to manipulate the different aspects of the HTML document, okay? So JavaScript and VBScript are generally more powerful. And of those two, JavaScript is more powerful simply because it's supported in real browsers, okay? JavaScript is supported in both Netscape and Intramed Explorer, although I'm sure Microsoft is calling it a JScript or something like that. Oh, have you seen that one? Do you think we'll just solve this one? Okay, so how powerful is this JavaScript anyway? What can it do? What can it not do? Okay, well first that's, I mean it's very powerful, so let's start with what JavaScript can't do. Okay, JavaScript cannot reach into the local file system. Okay, and this is what the, I know that you can use JavaScript to set cookies and stuff, but in general, JavaScript cannot reach into the local file system, so you don't have to worry about downloading somebody's HTML page and having a road, JavaScript applet or a road piece of JavaScript that's going to go to leading in hard drive, okay? JavaScript can't reach into your local file system. Now what it can do, okay, there's another restriction that I want to talk about. How many of us, well I suppose that if many of us are familiar with HTML, we're also familiar with framed documents, right? So that's when you go to a website and the website is broken up into frames, each frame holds a different HTML document, right? So in that case, the website is containing more than one HTML document at a time. Can JavaScript be in one of those documents and reach over and manipulate what's going on in one of the other frames? It depends. If the HTML document in those other frames is basically coming from the same domain, no, it can't. If it's a different website entirely, no, not really, it can't. Same applies for actually having another browser window open at the same time that has another HTML document loaded into it, okay? Okay, so that's what JavaScript cannot do. What can JavaScript do? Well, JavaScript can do a lot. Usually it's used for things like validating its legitimate uses or things like form validation and image swapping. You know, when you surf around the web and you move your mouse over and then you bar in the image light stop or something like that, right? That's done with JavaScript. Or you type in, you go to a page and you type in your name and you click the submit button, but you forgot to type in your last name. Even before the browser bothers to contact the server, a client-side process will occur where it validates the form input to see whether or not you forgot to fill in one of the fields, right? So that's called form validation. You do that with JavaScript. Now, what makes JavaScript powerful is that it can open up a sort of HTML document for output. So it can write arbitrary text to the browser. So it can create a follow-up page. It can dynamically create an HTML document. It can also look around in the HTML document that it's embedded in. So it can, if there's also a form on the same page as the JavaScript or even in a separate frame that it has access to, the JavaScript can reach right into that form and pull out whatever data is in that form. So JavaScript can suck the data out of a form. Now, so far, it still isn't clear how this could compromise security, right? Because the JavaScript is on your page. The form is on your page, right? Or the page of an internet service provider. So why would anybody write JavaScript to compromise their own form? Well, let's see what the problem is. Actually, before I tell you the big secret about how it compromises security, there's one more thing I want to cover. Is JavaScript only limited to, is its power only limited to the client side? Or can it actually interact with the server? Well, it can't directly interact with the server. But like I say, what it can do is it can read information from the form and what it can do is it can also send data. It can basically redirect the browser to a new arbitrary URL. So using a GET request, it can actually contact any server-side program anywhere on the web. So it could read the information from the form and then send that data to an arbitrary server by a GET request. Or it could change the data in the form so that it's sending bogus data to the back-end program. And also, like I say, it can redirect to any, it can create dynamically any follow-up page or it can redirect to any existing web page on the web. So it's still not clear how this compromises security. I'm just giving you a taste of the power of JavaScript. Okay, but what we've learned so far is that obviously, JavaScript can manipulate an HTML document in which it is embedded. Okay, so it has almost total control over the HTML document in which it resides, as well as being able to control follow-up documents or documents in other frames and windows from the same domain. So given that information, would it be wise to allow a user to post their own JavaScript into a public web application? If you were a portal, if you were a web service provider, would it be a good idea to allow users to post JavaScript under the same page as your own forms, the forms that thousands of users are going to be using to authenticate themselves and send data back and forth to your service? Hmm, let me think about that. No, it's not. Okay, but surprisingly, surprisingly, it happens all the time. So what are the susceptible online services? Well, the susceptible online services is any web application that gives the user the ability to post HTML, including JavaScript, that will be incorporated into the website's own HTML content and then viewed by other people. So what are some examples of these susceptible services? Things like webmail, online auctions, web-based chat rooms, basically any service with a chat area. So those are just in general categories, but basically any service. Any service where a user can post their own stuff into the web application is walking on on an Internet. So let's have a look at webmail services. Okay, so what we're able to do, we posted online working demos that stole user names and passwords from Microsoft's Hotmail, who's in JavaScript, both before and after they released a patch, Yahoo Mail using Java and Microsoft's Hotmail, again, using Shockwave. And we also found vulnerabilities in the webmail services of Yahoo, Like, Post, Fedora, Excite, Fedora, and all the sites powered by an online address in Mail, Excite. What was the real world effect if this had gone unnoticed? Well, the implications of stealing user names and passwords from these services is that it allows the bad guy to, in the case of a webmail service, to delete, send, and delete the victim's email, to check other mail accounts by mail checking. For those of you that use Hotmail, you'll know that you can configure it to check email on your other accounts. Access the address book, change the password of the webmail account itself, play around with preferences. Basically, it's just you wouldn't want a script to be getting into your webmail. And I know I won't help you crack Hotmail to find out if you're supposed to cheat on me just to answer a lot of your email. It's hard to get for some reason. Okay, so how does it work? How is it that a large webmail service, how is it that a posting Java script can affect a large webmail service? Okay. Here's one example of an algorithm that illustrates the problem. Okay, so imagine that you've logged into your Hotmail or some other webmail account, right? And you send someone an email, okay? And in many of these webmail services, you're allowed to use HTML to make your email a little more interesting, right? To send an image. I know you want to include a shockwave or something like that. So many of these webmail applications will allow you to include HTML. So imagine that your email, your webmail, actually contains some script tags and some Java script in it. Okay, so you send it off to the other person. The other person checks their webmail and what happens when they view the page? Well, the Java script starts running. And the first thing that it does is it sucks the authentication information from their form, okay? Then it goes and it changes every hyperlink in every frame to point to a different server-side program. Not Hotmail, for example, but instead your own server-side mailing program, okay? To be more specific, you're pointing to a server-side mailing program and you're including your own query screen, okay? Your own information you're going to send to the server-side program. And what information might that be? Well, in a worst-case scenario, it could be that authentication data, right? The username and password, for example. So the Java script redirects to this mailing program. The mailing program sends the username and password off to who knows who, Mr. Bad Guy, I guess. And the mailing program itself then does a redirect to the user back to the normal legitimate follow-up page of the web application so that in their eyes, nothing unusual has occurred. It's all transparent to the user. Now, up at the very top, I say that this is webmail exploit one, a snagging user and the password is old. And the reason that's old is that very few webmail services now will include any really useful or directly useful authentication information in their forms. Usually it's a little bit hard to decipher, more like a session key or something like that. Okay, so this may have worked a little while ago. It may work in a smaller service. It's still generally wouldn't work that well nowadays. Okay, something a little trickier. Let's have a look at how you could get the same effect using scoofing. Okay, so again, you go and you send someone, just check my time. Okay, you send someone an email that contains JavaScript. Now this time, again, the JavaScript alters every hyperlink in every frame of the web application. So guaranteed at some point, someone's going to click on one of these rigged links. Now when they do click on those links, the JavaScript dynamically creates a follow-up page. What does a follow-up page look like? Well, the follow-up page is an exact duplicate of a legitimate page that says, well, you have just timed out of this service, please re-log in and enter your username and password. And these web service applications generally really do have a page that says that, right? So in this case, you make it look exactly like that. You inform the user that they've timed out. Of course they really haven't, right? And then they wonder if they may experience that moment of frustration. Like, geez, I didn't time up. Oh, fine, whatever. And then they go and they type their username and password back into the form which you conveniently provided. And of course, that form is of your own engineering. And what does it point to? Well, again, it points to, let's see, what does it do? Yeah, so in this case, once you've gone that far, we think it's in your domain, right? So you can do whatever you want with it. You can redirect to a server-side mailing program, mail it back to the back guy. This is not so old. But this is, I think this still works, actually. We pointed this problem out in Microsoft's hotmail service. And they came up with a couple of patches. But as far as I know, it still works for there. You can actually send data in the message body of an email, but it still works as an attachment. I'm not using JavaScript, I'm using another client-side technology, which I'm going to figure out what it is. All right, example three. Here's another twist on the same theme. So let's say that the web service provider finally catches on and they say, hey, wait a minute, this JavaScript is bad news. That's it. I am filtering out JavaScript. So, fine, they filter out their JavaScript. Does that mean that the web application is now secure? Actually, no. What happens is, it turns out that you can do the exact same thing using a slight twist. You can do the exact same thing with many client-side technologies. So let's have a look at how you can do it with applets. In this case, you send someone an email containing a Java applet. What does the applet look like? It doesn't have to look like anything. It can just be a one pixel by one pixel applet that is white on the white background so the person can't even see it. It doesn't have to be a visible applet. So obviously, the user receives your email. They receive the applet. And the applet starts running. And what does the applet do? Well, it turns out that applets have a method available to them that can actually load our HTML documents into a specific frame of a frame set. I think it's called setAppletContext or something like that. So the applet itself has the ability to load an arbitrary HTML document into a different frame. So what does the applet do? Well, it loads a... Now, for those of you that are familiar with webmail service, you'll know that it's a framed environment, right? On the left-hand frame, you have your control panel. It's like compose new mail, check mail, whatever, all these options. And the right-hand frame, you actually have the email messages themselves, right? So what does the applet do? Well, the applet goes into the left-hand frame, the frame that contains all the... basically the control pad for the mail service, and it replaces it with the bad guys own HTML document which, lo and behold, is an exact duplicate of the control panel, okay? But of course, it's been engineered to do something slightly different. This new control panel is engineered so that every single link on the control panel, basically, is a link to load, guess what, a time-out message into the right-hand frame. Again, from the bad guys own mail server, right? Obviously, that page is totally under the control of the bad guy, and whenever the user enters their own re-login information, it's sent right back to the bad guy. Now, it turns out you can also do the exact same thing with Sharkwave. Now, the interesting thing here is that in the eyes of the browser itself, no security violation is going on with JavaScript, right? Because where is the JavaScript? The JavaScript is in an HTML document that's actually being served out from the web service itself. As far as the browser is concerned, that JavaScript is hotmail's JavaScript. It has free range to go into any frame, change whatever it likes, alter the forms, right? And why? All because the web mail services allow people to post up their own JavaScript and then gets incorporated into their own page. See, that's the problem. Once that JavaScript is incorporated into their page, it has free range. Web-based auctions, same general idea. We posted a modern-day working demo of JavaScript expert that stole user names and passwords of eBay users. And also interestingly, it can be extended to replicate itself by inserting itself into people's own auctions. And this was coined the Ebayla virus, and they caught a little bit of media attention. That was a pretty funny name, I thought. Ebayla, who bull-eyed it. Okay, so what is the exploit? In this twist, you post an item up for auction at eBay. And I don't know how many people here have actually been to eBay. So you know that when you post an item at eBay, all the items have associated descriptions. And when you go to post your own item up, there's a place where you can type in your own description of what the item is going to be, right? And eBay has decided to let you use any sort of HTML tags you want in your description of the item that you want to sell. Uh-oh. So in your description, you type out your script tags, insert some JavaScript, and what does this JavaScript do? Well, let's talk a little bit about eBay. It turns out that when another person comes, right, to view your item that's up for auction, what does that look like on the screen? Well, there's a description of the item, right? And right underneath the description of the item is a form. So that if you want to bid on the item, you can enter your username and password to make your bid, right? So basically, the description of the item is on the exact same page as the form where you enter your username and password. Oh, that's bad. Because as we all know, the item description contains JavaScript. What does the JavaScript do? The JavaScript will immediately start playing around with the form, okay? And there's a whole bunch of things that it can do. It can suddenly say, well, yes, thank you for typing in the username and password, but I don't think we'll be sending that to eBay right away. First, let's send that off to Mr. Bad Guy, and on a server-side mailing program that does a redirect to a normal, back to the normal eBay follow-up page, right? So from the point of view of the user, what's happened? You've seen an item description, the place to bid on it, the next page. They're told that their credit was registered. From that point of view, nothing unusual has happened. Okay, so what are the implications in this case with this web application? What are the implications of stealing the username and passwords? Well, in this case, you can use them to create new options. And what does that do? That actually automatically charges the victim's account, right? Suddenly, we're not just dealing with e-mail, we're dealing with real money. You can place the bids in the victim's name, you can retract the bids in the victim's name, you can change the victim's username and password, you can prematurely close an auction, and also, eBay has some really great powerful server-side programs that allow you to change the description of your own item even after it's gone up for bid. You can do that by entering your username and password. So, if I know your username and password, if I've stolen your username and password, and it turns out that you, yourself, aren't even using that as running an auction, well, now I can go into your auction, post my eBaila code into your auction. That can actually be done automatically so that in effect what you have is a virus that is spreading from auction item to auction item. Okay, somebody goes to the auction, they place a bid, if they themselves are running an auction, then suddenly the code is in there, auction item description. Now that was never actually, I never actually wrote that, I just wrote, I never wrote the self-replicating condo, although it would have been trivial to extend it, and eBay eventually patched the problem after two and a half months. Okay, so that's the bad news. What's the good news? Is there a way that designers can take advantage of this information to improve their site? Yes, there is. Okay, if you're running a kind of a web service where users must be allowed to post their own HTML content to public areas, okay? Especially to public areas that contain forms. Right? Then you should take the following steps. One, filter the content for client-side processes slash tags, right? So trot, you know, it's hard, but at least make the attempt to filter out script tags, applet tags, shockwave, flash, things like that, okay? And when the time does come for you to write your filtering software, a common mistake that I see is that the programs are written from the perspective of filtering in from filtering out instead of filtering in. What's the difference between filtering out and filtering in? Well, it's the difference between starting from the premise that you're going to let everything in, except for that, that, that, that, as opposed to saying, I'm not letting anything in, except that, that, that, that. The latter is what you want. You want to start with the premise I'm not letting anything in. Well, okay, maybe some plain text. I'm not okay, maybe hyperlinks. Maybe this, maybe that, right? So be choosy about what you let in. Don't try and figure out everything that you want to filter out because, you know, there are a lot of such ways to embed JavaScript and client-side processes into a webpage, and there's no way you're going to be able to keep up with the technology, the evolution of the technology. It's much harder to try and keep up with all the latest tags and all the different ways to embed it in the HTML than it is to just say, I'm not letting anything in, except you, you, you. And one of the reasons that it's really hard to filter out this client-side technology is because you can write a filter. Sure, it's easier to write a filter that'll go in and, you know, filter out all the script tags and stuff. But, you know, to do that, your program is going to have to be looking for certain tokens, right? It's going to have to be looking for HTML tags that have a certain structure. But browsers are so flexible. It turns out that even if you do type in a tag, and let's say you leave out the closing bracket, well, the filter won't pick it up because it's not a well-formed HTML tag, right? But the browser will figure out what the person's trying to do. So it's just really hard. Don't, don't even try. Don't even try to pick out what you want to, you know, filter out. I strongly recommend filtering in instead. Okay, also if you really must allow your users to post JavaScript information, to post their own JavaScript content, display it in its own browser window. And you can use your own JavaScript to make sure that that new window does not contain a reference to its parent window. Okay, that way any JavaScript that's posted by a user will not be able to make a reference to the parent and will not be able to go and start playing around with anything other than the window in which it is displayed. And obviously, you should never place a form on the same page or a follow-up page from all unfiltered content. So those are just some tips. Hopefully it'll propagate its way back to the designers of web applications. It's, like I say, it would be great if this information was used to maybe shift, but at least in some cases, you know, it's great to have excellent network security. It's really great to have great network administrators and have a totally secure network environment. But hey, if your web application itself isn't secure, you're spending a lot of money to protect stuff behind a firewall that can be accessed, you know, in a few lines of JavaScript, right? So what are the priorities? Okay, I'll take some questions now and unfortunately I have to leave in half an hour and go back to Canada. But I'll be up by the pool for about half an hour if anybody wants to talk to me before I leave and I'll take some questions now. Well, if you have a job, can you just say next to the mail application or stop the mail application? Just turn it off the job application so it doesn't go to the mail application. Well, when I say, when I've been, I'm talking about web mail applications, right? So I'm talking about things like hotmail and stuff like that. Now, there is also some ability to tinker around with things like Outlook and stuff. If you can shut out JavaScript, I mean if you're paranoid, yeah, turn off JavaScript, but JavaScript isn't your only problem, right? Yeah. Yeah. We see that person keep turning off their voice so they're going to be able to just take some time to say it. You're going to be repeating those words, aren't you? We're not having a third voice. I'm sorry. Any other questions? Yeah. Yeah. Can you either say that I've already got someone in the front with me now so I can get a question? Yeah. Yeah. Yeah. Yeah. Yeah. There have been a stream of polls that have allowed you to do things like that. Sure. Another approach is to look into your cache and stuff like that and mail that back. Usually, for the purpose of our demonstrations, it's seen that the way to catch people's attention that there's a security problem is to just steal the user names and passwords because that... The goal is to get the media's attention and to create a solution to the problem so you have to do something that people can identify with. Everybody knows what it means to steal a username and password. Yeah. Obviously, this isn't the only thing you can do. You can use this... If you're a designer of a web application, you want to patch this because I'm sure there are much more creative ways to do bad stuff than I've been able to show up on with my overhead. Yeah. Yeah, well, cookies are just another technology at the disposal of someone that's doing client-side scripting. So it's just a facet, something that you can take advantage of if you want to... You know, if you do suck some information out of somewhere, you may want to store it in a cookie for whatever reason. Yeah. Cookies, cookies in and of themselves are not inherently dangerous. They're just a tool. There's nothing particularly inherently dangerous about cookies. Okay, I guess I'm running out of time. So thanks a lot.