 A lot of them are actually detailed on the conference CD. Oh, hey, Jeff. Give a hand for Jeff Moss. We're going to take this off the screen for a second as we enter the IP address. No particular reason I trust each and every one of you. Well, Michael is entering the address information. My name is Dave Endler. Michael Sutton. We work for iDefense. iDefense is a security intelligence company. Just to give you a bit of background. Michael and I work for iDefense Labs, the security research arm of iDefense, and one of our keen interests is web application security. Today we're going to talk about a very narrow aspect of web application security, but it's an important aspect because these types of vulnerabilities that we're going to be talking about are extremely prevalent on a lot of websites and web applications, software, softwares out there. Additionally, it takes about half a second and half a brain to exploit these vulnerabilities. So we're just going to walk through some of the basics, go through some just basic concepts of how state mechanisms are applied in a web application sense and how you can easily break through those. So essentially we're going to be talking about how to brute force an application, not necessarily with the traditional username and password, you know, one, two, three, one, two, three, guest, guest, but brute forcing that state mechanism that's usually transparent to the user. While we're getting started, just in terms of the legality of testing these types of mechanisms, in the course of our research, we treated a lot of the holes we found and we are going to be actually demonstrating some live holes that we notified the vendor of about a year ago, they're still there. Most of them either ignored us or were somewhat responsible in their response. One in particular, and I'm not going to say much more about it, but one in particular threatened to sue us. So these types of vulnerabilities, what I might not seem that large, we go through the same sorts of responsible disclosure problems that all of you do as well. And if Jennifer Granick is in the audience, thank you very much for your help and that of your students. She was actually able to provide some feedback and did a lot of the leg work when we were contacted by this company. So I'm not going to say anything more about it and even if I'm completely drunk tonight, you're not going to be able to get me to say who it is. But I'm having a good time pretending it is. So we don't want to spend a lot of time on the network part, but while they work on that, I just want to give another plug. This is actually in the presentation, so it's not taking time out of it. I'm one of the leaders of the open web application security project, OWASP. And it's actually a group of volunteers, it's a group of people in an open source community trying to work on some projects that raise the general level of awareness of web application security. It seems in the last few years, we've just become, as an industry, we've just become aware that this is its own discipline. So if you take a look at the website now, I was going to walk you through some of the projects we're working on. It's OWASP.org, we're always looking for volunteers. I think there's probably a ton of talent in the audience. If you'd like to add your name to a project, and some of the projects are kind of a documentation side and software side, the documentation side is actually working on web testing and web building documents to actually provide guidelines. How do you build a secure web application? How do you actually test it afterwards? When we were all looking at the stuff on the internet already, there really wasn't anything out there besides possibly the open source testing method, from ideahamster.org. So take a look at the site, if you think there are things on there that interest you, drop me an email, email will be on the presentation shortly, I hope. Yeah, let's just get going. We might take a pause halfway through if we get connectivity, but don't want to delay much more. So here's just an overview of what we're talking about. In general, we'll just go through some basics, so we're all on the same page. Go through some fun exploitation examples, and then talk about what developers, essentially there's three audiences, developers, and when I say developers, I mean people who actually buy the software from the vendors, like BEA, WebLogic, or ATGs, Dynamo, or Tomcat, etc. And then what can users do to protect themselves? Essentially not much, but we're going to get into that. And what can vendors do, and particularly the onus of these types of security vulnerabilities are mostly on the vendors, unfortunately, to fix, before they actually get shipped to market. So essentially, let's not spend a lot of time on these basics, but you log into a web application. Web applications are typically protected by user accounts, varying levels. You might have a user access, editor access, administrative access. So you log in, and thereafter, the website, web server, web application knows who you are. You don't have to actually enter your username and password after each click, it's pretty straightforward. So in the traditional sense, if someone wanted to, they had nothing to do on a weekend, they could just enter in a bunch of usernames and passwords, and that would be it. Great. Traditional brute force of a web application. But what happens after you log in, since HTTP is a stateless protocol, developers essentially need a way to recognize that the person who is actually clicking the next click is you. It would be really bad if you saw other people's banking information and it would be even worse if they saw your information. In fact, I just said the same thing, but I said it like this. Thanks for the two people who got that joke. So essentially what happens is we generate a unique string, which is thereafter called the session ID. It's also called the token. I've heard people call the nonce. Essentially it's just a unique string that you know, and the web application knows so that, essentially, you can thereafter be recognized as that user. A decent example is you go into a bar, the bouncer asks you to see your ID in a credit card. You authenticate, so to speak. He stamps on your hand a unique number. That way when you go to the bar, you show the bartender your stamp. She looks at the number, references it, and she charges you a drink. Well, that's great, but what if I either see your hand or if I can guess what number you have? So essentially these are the two types of... Hello? These are the two types of exploitation scenarios. Is this too loud? Too echo-y? Okay. These are the two types of exploitation scenarios. So session replay is essentially seeing what someone is doing and mimicking them with their credentials so that some action they took occurs again. So, for instance, if I see Michael in the bar ordering a drink and say he orders a Bloody Mary, then what I can do is the typical example, I would walk over, mimic exactly everything he did with his credentials, and then order him 10 more drinks, and then he gets charged. Additionally, session hijacking would be if I dressed up like him, put the number on my hand again, either tied him up in the back or just... I don't even need to... Oh, wow, that sounds real good. Please don't fire a harassment suit. And then I would actually order drinks for myself charging him. So that gives you a decent example on what those two types of attacks are. So in theory, the username and password of a user is exchanged for this session ID, which is usually a long, hard-to-guess string. So in theory, you would think that the security levels and standards behind that long string should be the same as your username and password. Many companies make you go through many hoops of password selections because it doesn't satisfy this aspect or too many lowercase characters or it's based on a common dictionary word. Unfortunately, a lot of users and developers and vendors realize that that session ID is just as important to the authentication and state mechanism of the web application. So it shouldn't, in theory, be just as strong, but unfortunately it isn't. So, again, just to further emphasize that that session ID string should be just as secure as a username and password. Thanks for bearing with us, guys. I appreciate it. This is a fantastic turnout for first presentation of the day. I'm sure you guys all stayed in last night, took it easy. Nice to see you take this stuff seriously. That's great. We'll just give a quick overview on how session IDs are passed and the way that they're stored and set up. When we think of session IDs, we often think of cookies. That's not necessarily the only way that they can be passed. A session ID is just a variable, a variable that gets passed between the browser and the server, as David mentioned, as a means of maintaining state. So it can be stored anywhere that variables can be passed back and forth. That would, besides cookies, also include things such as directly embedded within the URL using the get method, or it could be a hidden field within an HTML form. And we'll show some of that and discuss why or why not. That's a good idea. As far as how that session ID, that unique alphanumeric string is generated, that's generally transparent to the individual that's actually coding the web application. They don't need to specifically come up with an algorithm to generate it. That's generally done on their behalf by either the web server or the web application server. Those of you who may be familiar with ASP pages, for example, there's a session object and creating a session variable is as simple as calling that object, giving the variable a name, which is done in the background. The IIS server does that for you. It's good and bad. It makes it a lot easier for the developer, but at the same time, you're somewhat at the mercy of that server that you're using. If they're not using a good algorithm to generate that session ID, you may or may not be stuck with that. Yeah, sure. Just basically two types of cookies, persistent cookies and session or non-persistent cookies, basically refers to how long that cookie is stored. The non-persistent simply stays in main memory. Persistent is stored on your hard drive. Persistent cookies are those that you would generally use when you have that remember me option on a website. And again, there's security implications to that because as we'll see, a session ID is effectively a form of authentication. So that needs to be protected. We'll get into specifics about that. This is just a diagram of what a basic cookie looks like just so you understand the structure of it. I've got those fields numbered one through seven, so I'll refer to them that way. First field, that's the name of the web server that actually issued that cookie and has the ability to receive that cookie. Number two is a Boolean variable, true, false, just determines if other servers on that same domain can also receive that cookie. Number three, the path to specific pages on the web server that can receive the cookie. So it gives you a greater level of granularity as far as whether that cookie information will be sent to. Four, another Boolean variable. That determines if you need a secure connection and SSL connection before the cookie will be passed and we'll refer back to that a few times because that's an important one. Number five, that's the expiry. I mentioned persistent versus session or non-persistent cookies. That date there, that expiry date is in UNIX time, so it's number second since January 1970, January 1st, 1970. And if you don't give it an expiry date by default, it's going to be a non-persistent cookie and be deleted when you close the web browser. Six and seven, that's the actual payload of that cookie or the data in a name value format. So in this case, the name of the session idea is Apache. That's how you would refer to it. And seven is the session idea itself. These are just some examples of various sites. You'll see that they all follow that format. Star Wars, they have the Wookie Cookie and the other ones are a little less creative than that. I mentioned there's various places that you can store that session idea. We discussed cookies. Another one is directly within the URL itself. You'll see at the end of each of these URLs that string is basically a session idea. And obviously that's not a very secure way of sending it because if somebody gets a hold of that URL, effectively your authentication is embedded into the URL. Somebody's not going to need to log in with a username and password, so not a secure way of doing it. But there are situations where you may want to do that. You see greeting card sites often use this basically so that a user can go to a unique greeting card and will walk through those examples as well. And the third thing that I mentioned as far as how session ideas can be passed would be within hidden fields within an HTML form. Again, not a very secure way of doing it, but there may be situations where you want to do that. I think people often mistakenly believe that it's more secure than it is because an end user can't visibly see it in the way they can see a session idea embedded within the URL. But as you know, there's nothing to seeing this. You just have to view the source code of the web page. I just want to put this entire talk sort of in perspective in that we're talking about one very specific technical vulnerability on web application security. But with anything in security, you need to look at the big picture. I mean, you could have a fantastic algorithm. It gives you a very unique pseudo-random, difficult if not impossible to guess session ID. But if other aspects of security that interact with that are very poor, it doesn't do you any good. I mean, let's say your policy called for that cookie to be a persistent one, so it's stored on the hard drive. Who cares if it's a hard to guess algorithm or somebody can grab that cookie and there's poor physical and logical security around the server? It doesn't mean anything. So just keep in perspective that this is only one aspect of web application security. We'll walk through an example. We won't be able to go to the web page, but on this one I mentioned that greeting card sites are a good example of a site that embeds a session ID directly within the URL. And you've all walked through this. You know how it operates. You want to send a greeting card to somebody, you log into their site, you make the greeting card, and they receive an email, something like this, that says, click on this URL to see your greeting card. And at the end of it, it'll have the session ID right in there. Now, when you first look at it, the session ID is that last 16 characters there. It actually, I mean, it looks random. If you only look at one, you know, it's just a long, hard to guess string. So if you want it to brute force that, you're going to have to go through 10 to the power 16 combinations, which will take a very long time to do. But the only way to see if something is truly random is to look at more than one and see if there's anything in common between those URLs, those session IDs. So in this case, what we did is just kept regenerating that greeting card over and over again, just technically, literally by hitting the back button and doing it over. And when we started to look at those variables, we noticed that they weren't all that random. The first three characters at 83 seems to be some kind of a constant, never changes. And then the next, I don't know, seven or eight characters, that actually turns out to be the date. And that's an important thing that you want to be careful when you're generating a session ID that it's not using something that is known to the user. And obviously if the user is creating that greeting card, they know what time they created it. So it's easy for them to figure out. In this case, we did this on July 25th to 1221. And you can see that in the 7, 25, 1221. And so what we end up with is actually only four or five digits that are actually truly the random or supposedly random portion of that session ID. And in this case, they're actually sequential, so they're not even that random at all. So we've gone from having to brute force something that was 10 to the power of 16 down to something that's about 10,000, 100,000 digits, which is much more reasonable. We'll save the demo on this for a second because we'll either, if we have internet access, we'll try it that way. If not, we'll switch over to the other computer. But basically, if you want to brute force that, you've got 10,000 combinations. One way is obviously get a web browser to start typing it in manually. And if you've got nothing better to do, that might be a good way to do it. But the easier way is to automate that. You might want to write a Perl script or something. In this case, we actually wrote a tool that will allow you to brute force session IDs in various scenarios in cookies within URLs. That's the tool right there. We'll demo it on the other box. But actually, David, do you want to just talk about the sections there? So essentially, we were looking at a lot of web applications in our audits and past lives. Really, the only decent way to tell if a session ID is predictable is by looking at it. It'd be nice if there were some need AI program or neural net. You could just run it through, and it would have a yes or no button. And yes, predictable, no, non-predictable. But unfortunately, the easiest way to figure it out is just by looking at a bunch of session IDs generated in sequence very close to one another. So essentially, this is a tool that has three aspects to it, three mini-tools. I'm not sure if you can see it. This should be on the DefCon CD. It's an open-source tool. You can look at the spaghetti visual basic code that I put together. Essentially, the top part allows you to sample those session IDs that are generated just from the website. This is version one. Version two would be nice if you could actually generate the session IDs after you log into that website so you'd have to actually include the post information in that as well with the credentials. So essentially, you can just, if we have time later, if we get network connection, I'll show you. Using redhat.com is the example. They actually use the IP address, your IP address to append to, you know, some bit of entropy, some random numbers. They don't use that necessarily for authentication, but it's just a decent example. This middle part of the tool is a basic authentication boot forcing, which really isn't within the scope of our presentation. But we had all the same hooks in there to do a lot of this anyway. So it might as well, it was kind of an added bonus. The last part is where the real meat of this boot forcing is, and I'm just going to put these two windows sort of butt side by side, almost as if we're running it in real time. If you switch your eyes really quickly, you may actually see some movement, but I'm not sure if that's from what you were doing last night. Essentially, what you can see is we pasted a really long URL into the URL field. The scenario is essentially, if I know that Michael sent his girlfriend, you know, a really scintillating greeting card, and I can figure out, you know, when the time was, at least I have a range to work with. That was it? Like, no. Oh, sure. What we can do is we'll just, we'll show you another example. We have a standalone box with a web server. At least you can see some of the cookie generation. But then you paste that URL in and use a combination of regular expressions to tell the tool which characters you want to grind through. So we'll just give you a brief demo on this computer. So this, we'll just run it locally off of my machine. This, I apologize, I'm totally not a redneck. This was an application from a school project, and this morning as we were in the hotel room, we're like, we need something that makes session IDs. I was like, cool, I got it. It's left over from school. But it just ignored, all right? Pretend it's like a Linux site or something. Michael has a fancy NAS card. Is that an oxymoron? Sorry, wrong tool. So we have IIS running on this sort of standalone. So stop the new laptops. What we're doing is we're just, you can just slide through the window. Yeah, sure. So all we're doing is we know that the website uses session IDs. And so we want to see that randomness. So we want to generate a succession of them. So with that first part, we're able to just put the URL directly into there. Say, we want how many cookies, in this case 10, and just get the cookies. And then it's spit out in the bottom. In this case, they are fairly random. I asked, there's a reasonable job. But that's the first step of allowing you to look at it and then decide, is there some non-randomness that I can prove for us? Actually, why don't you walk through the regular expression, please? Sure, switch one. So the... We'll see the URL and cookie field. You can actually brute force either. If you wanted to just brute force the URL, we'd put the regular expressions in there. If you want the URL constant, you paste the cookie in. And essentially, it takes care of all the formatting for you. You just have to have a basic variable equals value format here. So we have ASP session ID, blah, blah, blah, blah, equals, and then it's really long stream. So let's try and just brute force the last digit. We'll put the starting digit or the starting character in there, which is going to be A. I don't know if you can see this on the screen. Okay, so I'll just walk you through it. You put the character there and essentially, if you just click on the tab, you can test it out when you try it out on the CD. Just click the info tab. It's kind of obscure, but once you actually look at it, you'll understand what the ranges mean. You can do 0 through 9, little a through little z, big a through big z, and then the combination of those together. So essentially what you see here is us grinding through each one. You'll see two radio buttons at the bottom. The first one is just, you know, click on it here. Just look for a non-foreforeheader, which means you're grinding through a URL, in addition, you know, with possible cookie in there, and you're getting a page back. Now, assuming that the web server hasn't customized their error message, you may get, you know, a 200 success. This is the web page. Congratulations, you've authenticated. Some websites have custom error messages, like, you know, these aren't the web pages you're looking for. Go away, nosy, et cetera. So what you can do is actually click on this radio button and tell it what a successful web brute force would look like, what string in it it would have, such as welcome to your account or, you know, et cetera. So that's the tool in a nutshell. Why don't you do mini browser as well? Yeah. And this is just another tool, mini browser, that we like to use. Essentially, it's just a browser with different fields that you can kind of watch the transaction, the web transaction take place. So this is Michael's NASCAR login. If you look at the log, you'll see the cookie actually getting passed back and forth. If you actually click on cookies, you can see them all listed out pretty nicely. We're going to show you another example of this later. I'm sorry? This is vision, visual basic. It's open source, so you can actually see the code for yourself and improve it. Send it back to me and I'll take credit for it. I'm just joking. If you want to actually help out with it, I'd be glad to post a new version with any improvements. And there are some improvements I have in mind, so. It's actually search size again. So, okay, why is this bad? Obviously it's bad because you can actually get into a user's account without their username and password. It's really easy to exploit, as you saw. Now you all have the tool. It's even easier to exploit. Unlike typical login scenarios like an operating system or a lot of other web applications, if you have five failed logins sometimes that account is locked out. Group forcing session IDs, it's really hard to detect a fail. There's no necessarily a failed login scenario in group forcing a session ID or getting a bad session ID. Additionally, there aren't a lot of intrusion detection systems that detect these types of attacks. I would say none, but I have a feeling that some are actually coming out that would start to detect these types of exploits. Additionally, really the only way you'll know that someone is trying to do this is by looking at your log data, which I don't think a lot of us do. Essentially, you'd either see a lot of error messages or you'd see a lot of error messages that are followed by the successful login on your access, your successful access log. I'm just going to mention that this last point. There's a myth that I'm sure a lot of you run up against that SSL secures all, and obviously it doesn't. What I wanted to say is SSL server side doesn't really do much to protect you against these types of attacks. When I say server side, which really describes most of the SSL certificate scenarios out there, the web server has a certificate the client doesn't. In another PKI sense, if you wanted to actually issue certificates to your clients, authenticate them in that way as well, that might actually protect against a lot of these attacks because it would redirect you to an authentication screen. Unfortunately, this really isn't feasible in a business sense. If you're in a very small environment, you could do this or an intranet. I just wanted to point out kind of a news hit that occurred for this type of attack. Essentially, it's interesting that a few years ago web application security was a dot on the radar. Now you see export scripting hole exposes hotmail and you see this on cnn.com. It's good in a way because users and the internet community are becoming aware that these types of attacks are bad. Unfortunately, this was based on a bug track posting by, I think, Mark Slenko. He said, hey, I'm a Verizon wireless customer and when I logged in, I got this URL. I'm not sure if you can see it on the screen. There's a portion in red and that's an ID. He got redirected to this URL. In fact, all Verizon wireless customers were redirected to a URL similar to this. The only difference was that number was different. Well, it seems that by incrementing or decrementing that number, you can see other users' information, billing information, credit card information. Oops. So this is good in a way because I'm sure Verizon fixed it very quickly once this news item came out. It's bad because who knows how many other customers were affected. I'm not sure if you can see the screen. SecurityPimps.com. It's actual site. It's actually my site. I'm not really doing much with it except just playing around with Flash and maybe forming a hacker group someday. I'm not sure we'd have to be based outside of Nevada just because of the name. We're outside of Las Vegas in Nevada. That joke will bond. So essentially, I host this at register.com. Register.com lets you as a registrant. It provides you a web access portal, web application that you can manage your domain. It's the domain manager. So you log in, change any DNS settings. I was trying to change the setting one day when I forgot my password. So essentially what you do in the Forgotten Password Scheme is you put in the domain name and an email gets sent to the administrative contact of that domain no matter who you are. You can cause this to occur. You can cause the Forgotten Password to occur. So the email got sent to pimpdaddyatsecuritypimps.com. That's me. I'm not going to make a joke about it since the first one bombed. And we're running a long time. So essentially you get this long URL. And in a three-day time period, someone visits that URL. You're not even asked for your old password. You can change the password. So think of it this way. If I know your domain or if I know a domain that's hosted on register.com, I can plug in the domain name and figure out that... Well, let me go back. By pressing back and submit a few times, I got these URLs in my email as well. So obviously those session IDs after... Can you see the numbers? Sure. If you can't, essentially we whittled down it was a 12-digit session ID to what was now five. So if you had a domain on register.com and you know someone else did, you could submit them at the same time. Essentially figure out what that was in proximity and probably shave that time off so that I think I figured it out. If you wanted to submit it when someone goes home from work around six and try and brute force it when someone actually shows up again around eight or nine, you could probably do that 50% of the time if you were doing maybe one request a second. So... We won't go through these examples. One is defilm and one is send-ematic. I'll just explain really quick what they were. That's a situation where a session ID was passed directly within the URL and there was no randomness. They were just purely incrementing that number. Defilm is where you make your own little personal flash movie and send it to somebody. And they weren't at all using that session ID for security. They were just using it to allow you to see a unique video or whatever. And just the important thing to note there is that they may not have been planning security in there because you can just increment that session ID. You'll see somebody else's video or send-ematic is one of those sites where you set up a party and you send invites to people. If you increment it, you can see other people's parties and invite your friends to their party and all that kind of stuff. And even though they may not have used it, they may have not planned security in there, their users may not have that same perception. They may think that they are the only people who can see their greetings and their invitations. So never design something to your security specifications. You have to design it to your end-user specifications. If they think there's security in there, find out there's not, that's not a good way to keep your clients around. We have about 10 minutes. We're probably going to run five minutes late just to let you know I'm a big believer in doing things on time, especially having brief presentations and agreeing to end when you're going to end, but we started a little late. So just to let you know, freeservers.com is where I host security pimps. Again, the same sort of scenario. You have a web application, you log in, and in this case I actually can change the content. FreeService is a free web hosting service. Essentially you can pick from a bunch of domains. This one I just picked testing, 123.itgo.com. So essentially you log in, username and password, you go into your login screen, you can change content, you can upload content, delete content. So using mini browser, just as an example, we can't do this online, but we log in, you can see that our cookie is actually, go to the next screen, you can actually see it. So it looks like a fairly random cookie, but every time I logged in, so a lot of developers make the mistake of obfuscating, obfuscating, say that in the morning. The session ID with just a very basic encoding mechanism like base64 or hex, and they think, haha, I don't know how to figure that out. Well, just for kicks, I put it through a base64 decoder, and security stats actually has a decent amount before we go to this link and paste it. You would see that string decoded and base64 decoded is my domain name, colon, and then my password. Just to let you know, everyone who's firing up your browser has changed the password already, so don't try and log in. So essentially, this is a case where I don't necessarily need to brute force it in a traditional sense, character by character, that can use a dictionary attack. So what I did, wrote a Perl script which is included in a paper on your CD. All these Perl scripts are included. The dictionary attack takes the password words, pens it to the domain, runs base64, and then tries to load a browser and essentially sees if we get it successful while logging, so, yeah, just go ahead. Or if you really, you know, have nothing to do on the weekend, you can definitely brute force every single character but, you know, I bothered. And just to mention, some sites actually use the URL in the cookie to store the session ID. We showed Amazon earlier as one that actually stores the URL before you raise your hand after and say, well, they use the cookie as well, it's true, but they actually use a lot of the same information in the URL. Let's just store it in the cookie. So while you think you're really clever by using a cookie to store this information and you're doing all the things you should be doing by storing it over SSL or sending it over SSL, if it's also in the URL, then someone may still be able to get that information. So a lot of proxy servers store that information in logs, so somewhere to break into your proxy server and see a session ID from, you know, a past login, that authentication information is right in there and viewable. Essentially, just to break the six common problems behind session IDs, the first four actually relate to brute forcing, so weak algorithm. Obviously, if I generate an algorithm, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, blah, blah, blah, blah, 12, then it's predictable. Reverse engineerable as well. You just saw username and password and through some encoding mechanism. The second problem, no form of account lockout was really no real way to combat this. If you saw an IP address coming in trying to brute force a session ID, you can't exactly lock out an IP address on the internet realistically, especially because of the way ISPs tend to randomize IP addresses like AOL. I believe AOL still does this. After each click of a web browser, your IP address actually changes. So, that's just another problem to exhaust that exacerbates this. Short T-space. I thought of a decent example. This is my luggage lock and essentially, assume that there's a random code each time every time I walk it. It's great. You need code every time, so no one can guess it. Unfortunately, it's easy to brute force. I have four dials on here, 0 to 9. Now, obviously, someone can brute force that probably within a day. Again, if they were doing all these other things on that weekend, they had nothing to do. What we can do, though, is if we wanted to increase the key space, we could either create a bunch of dials that go all the way out for two feet, but also had 0 to 9 on it, or we could increase the length of the dials, including some other characters on it. So, I'll just give you an idea of what I mean by key space. Again, indefinite exploration on the server. If you click the Remember Me button, you'll get an attacker. However long they want to brute force a session ID, pretty straightforward. Not going to spend a lot of time in the last two. Essentially, you all understand that if you capture a session ID in transit, or if you're able to get a user to load some malicious Trojan horse that then sends it to you, you can then log into his application. These are just some tools, all three tools that you can use as a website web application developer to help you, or as an auditor of somebody else's stuff or whatever else you guys choose to use it for. The first one, Session Auditor, that was a tool that we showed you, the one that we wrote, and allows you to brute force a session ID. WebSleuth is a great tool. It does a lot of different things. Sessions Auditor is actually embedded within that tool, so you get the same functionality, but WebSleuth allow you to do a lot more. And then the last four, WebProxy, HTTP Push, Achilles and MiniBrowser. We showed you MiniBrowser. Those are all effectively personal proxies. So what they're allowing you to do is not to brute force that session ID, but to intercept the communications between the browser and the server so that you can see what's happening in the background. You can see how that session ID is getting passed. And with most of those, it'll also allow you to adjust things before that session ID is sent. So you're sort of doing a manual brute force. What can you do as a user? Obviously as a user, there's no mercy of the application, the web application that you're using, but there are still some common sense protective measures that you can take. One, logging out when your session is done so that if they're using that session cookie to use the session ID, it'll get wiped off the server. And so if somebody steals it, it's not going to work for them anymore. Don't select your memory option. Memory option is good in some situations if it's security's not involved, but all that's doing is maintaining that session ID on your hard drive. And if somebody has access to your hard drive, they can grab it. And everybody knows where to find it. Netscape stores a cookie in a certain place. IE stores it in a certain place. It's always in the same place. Then that ties into the third one. Use SSL when you can. David mentioned it's not perfect because if you can get something at one of the end points or at a proxy in the middle, you can still intercept it. You can't do anything with that session ID, which is obviously a good thing. And patching your browser with anything, you've got to keep the patches up to date. The big thing right now is cross-site scripting attacks. We see new ones every day. And keeping your browser patches up to date will help you from not somebody, help you from not allowing somebody to grab your session ID through a cross-site scripting attack. And, you know, a session ID is an authentication mechanism. So treat it the way you would treat a username and password. If you're passing it around in an email, just keep that in mind. That's what it's doing. Just to follow on to cross-site scripting. Obviously, cross-site scripting is a server-side problem. But there are a few browser-specific issues that some cross-site scripting works on older versions of Netscape that don't work on the newer versions, etc. Obviously, a lot of cross-site scripting stuff is dependent on the vendor to either fix or make sure it doesn't affect authentication. So what can you do as a software vendor? If you actually hear in the audience and you've grown your facial hair out in the last week wanting to mingle in. These are the things that software vendors can do to make sure that their applications are more resilient to application brute-forcing. Obviously, you're not going to be immune to it by the very nature of most of these state mechanisms. Regenerate the session ID after a set period of time. This helps if someone actually sees the information in your proxy. It just makes it harder for an attacker. My favorite is to create booby-trapped session IDs in the application. So if you have essentially five minutes, okay, my five-minute overplant isn't going to go over well. But essentially, just create a booby-trapped ID so that one that never gets generated but one that you can detect when going through a range. When practical, limit the successful sessions to specific IP addresses. Again, this will only work in an internet environment. This really isn't realistic for an internet application in an environment where you have control over the physical aspects of where people are logging in. For instance, if you only want someone to log in from this desk and the sock, then really that's the only way this option will play. Auto-expire the sessions and someone walks away. And the last one is something cool. It's kind of hard to explain, but essentially we talked about a replay attack. If you're going to check out of a shopping cart, someone actually sees that checkout request and then just fires a bunch more checkout request so you get, you know, on Amazon, you get 10 copies of Comma Stutra for dummies instead of the one you ordered. Essentially what you can do is the page before that put a nonce or another type of session ID that requires you actually come from that page and Yahoo does this, they call it a crumbs, that's their official term for it. Most important, just use a good algorithm and make sure the inputs to that algorithm aren't based on time or user idea password. Some good pseudo-number, random generators, e-gads, YARO, Y-A-R-R-O-W. What can you do as someone who actually has to buy this type of software? Well, a lot of this software actually does have the ability to generate hard-to-guess, hard-to-boot-for-session IDs, you just have to configure it. Some of them have a few levels, but unfortunately out of the box they are very, very low level. And again, test your system. You should be able to know as a vendor or as a developer if your system is prone to these attacks. It's your responsibility in a sense to your users. Why don't we leave just a one or two minutes for questions but essentially we talked about OWASP and we already talked about OWASP. In conclusion, users, just be aware. Developers, configure your sites properly and your systems properly and test them. And software vendors, fix your software. Just some resources. Yeah, if you have questions, you want to just come up after. Unless you really have one that's burning a hole and you want everyone to hear. Yeah, just one question, sorry. I'm sorry to say that once more. Question is, can you use the SSL session ID for session tracking? There's actually a decent thread about this. I believe on the web application security list, the answer is no, you really can't for a lot of reasons. One, it was just never meant to integrate well into web applications and often you have proxy servers that may strip that out before they actually get to the web application. But if anyone wants more detail on that question please do. Thanks for attending. Sorry, we started late.