 All right, my name is Rogan Dawes. I'm here representing the open web application security project. Have any of you ever heard of it? OWASP, a few people, great, wonderful. I'm an application security engineer for a company called Aspect Security. Aspect Security is heavily involved in OWASP and they support my work on web scarab as well. So I just give a bit of a quick plug here. All right, so OWASP, for those of you who don't know what it is, is short for the Open Web Application Security Project. It was founded around 2000 by a group of people that have been chatting on a mailing list, discussing various web application security issues, starting from the early SQL injection things that people like Rainforest Puppy came up with. And they realized that something really needed to be done in order to address these continuing security problems. So it's made up of a group of security experts from around the world and just interested individuals, and they're contributing their time because they believe that this is a big problem and something needs to be done. We produce commercial quality tools, as well as some very good documentation. One of the big products of the OWASP project is the top ten most critical web application security vulnerabilities. This list has been adopted by the FTC, American Federal Trade Commission, and the payment card industry, which is a consortium of Visa Mastercard, MX Diners, etc., as the standard for application security. You can read the ten most wanting list. Basically, it's really intended as an awareness document to highlight for managers and project managers and that sort of thing. Just what, how big the problem is and to make people ask the question, do I have these kinds of problems in my applications? Okay, so, you know, sorry, excuse me, let me just fix this screen. Tried to get too clever with the resolution. Okay, so it's a bit better. All right, so those are the areas of the top ten. Garrett was talking about validation in Kake PHP being such an important thing. Failing to validate your input parameters that you then process in your application is one of the core problems. That lead to security vulnerabilities. Broken access control, not checking whether somebody is allowed to perform an action correctly. Broken account and session management, allowing people to brute force usernames and passwords, allowing people to access functions without checking their passwords correctly. Cross-site scripting, buffer overflows, command injection, failing to handle error conditions correctly. These have all led to pretty serious vulnerabilities. And so this was just really an awareness just to make the application owners or project managers ask the questions of their development teams. Another very good documentation resource is the OWASP guide. The guide for building secure web applications and web services. One of the big problems that we see is that there is a lot of information about how to do things, but there's not a whole lot of information about how to do them securely. And so the guide is intended to be that document that gives you the information about what sort of requirements you should have in your applications from a security perspective. It has code samples in various languages, so it's a very, very good resource on how to actually include security in your applications. Another tool from OWASP is WebGoat. It's a deliberately vulnerable Java web application, and the idea is that it provides a safe environment for learning about security vulnerabilities. The obvious thing here is that you can't just go out and test if an arbitrary site on the internet has got security vulnerabilities in it because you're likely to get yourself into all kinds of trouble. So don't try any of the things that I'm going to show you today on sites that you do not have permission to test. Some of you may have heard the story about the Tsunami Hacker, a guy named Daniel Cuthbert living in the UK. When the tsunami hit in the far east on Boxing Day 2006, he decided that he was going to donate some money to a site that was soliciting donations. Being a security consultant, he thought, well I should really check to make sure that the site is secure before I hand over my credit card details. So he tried a couple of things that were unsuccessful. And so he went ahead, entered his credit card numbers and made a donation. Those couple of tests that he had tried triggered off an intrusion detection system, they tracked him down because he gave them his credit card number and he was convicted. So don't try this without proper authorization. Another of the important OWASP resources is the local chapters. The local chapters basically provide a forum for people who are interested in application security to get together and discuss what they're doing, how to do various things in the application security field. Free and open to anybody to participate. Go to the OWASP site and see if there is a local chapter in your area. If there isn't, maybe you'd like to start one. Typically they meet on a monthly or quarterly basis, just depending on the amount of interest. And there'll be presentations and discussions of the key application security topics. Basically whatever people are interested in, they'll generally find somebody to talk about it. Another thing that the OWASP project does is they host conferences periodically. In the past, we've had two annually. The first one in New York was just the first one for that year. And then we've had one in Europe and one in America each year since. This year, there are going to be three, one in Australia, which is a new thing for us. And that's actually next week. And then one here in Brussels for the second time, coming up in May and then New York in October. Some of you may have participated in the Google Summer of Code. OWASP has its own season of code, autumn and spring of code so far. And basically just like the Google Summer of Code, the intention is to encourage people, participants, existing or new participants to work on OWASP projects. One of the things I haven't mentioned is that OWASP is very focused on making sure that the resources that they provide remain freely available. There's no subscription this or if you pay extra, you get access to something else. Everything that OWASP does is freely available. You don't have to be a member. You don't have to sign up and pay large amounts of money to get access to anything special. Everything that is there is readily available. And as I mentioned, it's done by volunteers. So you don't always get the kind of progress that you'd like to see. So we encourage people by sponsoring them in these season of code projects. So some examples of the output from these sponsorships. The testing guide is a good document that explains how to actually test for various vulnerabilities. The anti-SAMI project, how many of you, did any of you hear about the MySpace worm? Yes, Sammy is my hero. Sammy is a guy who wrote a worm that took over MySpace. Well, basically it brought MySpace down in a period of around, I think, 18 hours. Basically what he did was he found a cross-site scripting vulnerability. Somebody visited his profile. It added Sammy to his profile as a friend and added the text, Sammy is my hero. And then when somebody else viewed that person's profile, it just expanded exponentially from there. And he ended up with something like a million friends or something on Facebook. And the site just shut down. It just couldn't conceive of somebody who was so popular. So actually one of the aspects employees created the anti-SAMI project, which is a mechanism for sanitizing arbitrary HTML content. So it translates it into XML, pauses out anything that is not a recognized safe piece of HTML or safe attribute of an HTML tag. And there are various different profiles, depending on what you want to allow and what you don't. So that's actually a pretty neat project. And then another example, the WebGoat solutions guide. I'm going to be showing you guys WebGoat shortly so you can see what that's about. The solutions guide, obviously, helps you to compete the various lessons. So we've paid out more than $100,000 in sponsorships over those two projects. So if you are interested in application security, maybe take a look see if anything interests you when the next one comes up. OK, so what's the problem again? Application security, in many cases, an organization doesn't even think about it. They simply trust that their developers know that they have to produce secure code and they know how to do that. And that's even if they've ever thought about it. It's like security, yeah, that's being taken care of. Our developers know what to do. And in many cases, that trust is misplaced. Developers don't know that security is their responsibility. If you're working in an organization, many times you ask a developer who's responsible for security in your company. And they'll say, yeah, we've got a security department, network security. They do all the firewalls and stuff. They're responsible for the security of our applications. And that's absolutely not true. You've got a hole punched through the firewall, connecting straight through into your applications. The users are making a request straight into your application. And so your application is now part of your security perimeter. And so you need to make sure that your application is processing those requests correctly. I got a smiley face against that search engines being part of the problem. But in my opinion, it is to a certain extent part of the problem. And let me explain why. Quite often you'll go out there. I think many of you are self-taught, right? Even been on formal courses on how to learn to develop web apps and that sort of thing. So you'll start off by, well, how do I create an HTML page? Google, and you'll find W3C HTML, and maybe some how-to guides. You think, well, OK, here's my static page. It's all very nice. How do I add some functionality to it? So you'll go out and your Google's like, ooh, pull some records from a database. And you'll come up with 100 hits, and you'll take the first one. You think, ooh, that looks slightly complicated. Maybe there's an easier one. And eventually you'll find one that gives you a one-liner on how to do it. And there is not a single piece of information that the word security has never mentioned anywhere. So you don't even realize that what you're doing is potentially opening up your applications to security problems. So they're not really part of the problem, but it's the whole problem that people put out this information, all of the how-to-do things, without mentioning security as part of the issue that you need to be aware of. So ultimately, lack of awareness of the problem, not knowing that security is an issue, is a large part of the problem itself. So what can we do? Some of the things that the OS project is trying to do is educating people, providing the documentation. We also do a lot of training through SANS, the SANS organization. We provide the web application training. We provide tools where people can experiment with the various vulnerabilities, for example, WebGoat, get people who know what they're doing to actually review your code for security vulnerabilities. And then, of course, you can try penetration testing at an application level, which is where WebScarab comes in. And that's ultimately why you guys are sitting here. So WebScarab is one of the flagship OS tools. I've been working on it since 2003. It was actually my first Java program I've ever written. And you'll see the effects of that on the next slide. Some of the key features of WebScarab, basically it gives you the direct access to the underlying HTTP protocol. One of the things I think that many people don't realize is that when you're programming to an API, that API is shielding you to a certain extent from the underlying wire protocol. What's actually going across the wire? So you call a J2E API, getCookie or getSession. But do you realize that it's actually setting a header, which has setCookie equal JSession ID equal something like that, being sent across the wire at a fundamental level? So being able to see that and seeing that things like hidden fields are no different to a regular field when it's being sent across the sent in a post request, I think highlights why you shouldn't be doing things with hidden fields. So one of the key features is that it is an intercepting proxy. You can place it in between your browser and the server that you're connecting to, and your browser will make the request to the proxy, i.e. WebScarab. WebScarab can then stop that request, present it in a window, let you take a look at it, modify it, change it in any way you like, and then send that request off to the server. Intercept the response that comes back from the server. You can modify that if you like to change the behavior within your browser and then just keep going. And it also supports SSL. So you see a lot of people that you click on the security button on their website. Oh, we're using SSL and firewalls. And they think that they've done a good job when it comes to security. The reality is SSL doesn't protect the site and it doesn't protect you against many attacks. All it does is stops people from eavesdropping on what's going on between you and the server, but it doesn't stop you from tampering with what's being sent to the server and it's not going to stop an attacker either. It provides a session history, so you can actually see all of the requests that you've sent and it's got a bunch of various plugins. For example, a spider that will go out there and just download all the links that it can find. A fuzzer, which will try various input sent up to the server to see what comes back. It's got some web services support. It's fairly rudimentary, but I'd be happy to take patches if anyone wants to fix it up. And then it's got some scripting support using the bean scripting framework. Okay, so this is the classic version of WebScarab. Some of the problems, it's clunky as hell. It's completely undiscoverable, unintuitive, et cetera. When I was writing it, I knew nothing about human interface guidelines. And to be honest, I was really writing it for myself. I knew how to use it. You know, it didn't necessarily have to be easy for anybody else to figure it out. And stupid things like memory leaks and so on. So yeah, it's clunky. But the idea is pretty simple, basically. This is the classic version, not the ng version that I'm supposed to be talking about anyway. So, the summary panel shows you what's happened so far. And then there are a bunch of plugins across the top. You can see basically what WebScarab thinks the site looks like. So the hierarchy of the sites that you're looking at. And then the history of all the conversations that you've looked at. And you can double click on them and it'll bring up the details of the request and the response that came through. Okay, so this is the ng version, next generation version of WebScarab. As you can see, it looks a lot nicer. And it's got a couple of neat features such as the proxy toolbar. Just along the top there. Starting where it says none and ending at the green box. That's actually a stays on top window. So it's always there and always ready for you to be able to say, yes, intercept this next request or don't intercept. Previously, you'd have to switch back to WebScarab, go to the proxy tab, turn it on, turn it off and it's just a complete pain in the back. So that sort of thing makes life a lot easier. It's all dockable and draggable and fancy like that. And the important thing is that it actually, it's all integrated and makes sense in the way that the commands and the options and the forms, et cetera, work. So that's a big improvement over the old version. So the improvements, user visible ones are making use of the spring rich client platform, which as I say is a platform for developing rich clients. Some of the problems in the old version, if you have multiple views on the same data and you've modified in one place, it doesn't necessarily always update correctly into other places where that data was being viewed. That's now all kept consistent. New content type editors, WebScarab has got certain editors to allow you to view the content that is sent to the server and sent back from the server in various ways. For example, if you're sending XML, it'll pause it out into a tree and you can modify it using a tree view. If you're sending JSO in requests, it can actually also pause that out and make it easy for you to see what's being sent and modify those and so on. And then under the hood, the old version of WebScarab used to use a whole series of flat files in order to store the history that got out of control very quickly. You make sort of two or 3,000 requests and you've got four to 6,000 files sitting in a directory and that slows things down pretty dramatically. So all in all, it's a pretty big improvement over the old version. And so I'd like to show it to you. No, it's Java, so it's cross-platform. So no worries there. Okay, so there it is. I'm going to bring up a browser as well. So this is basically showing you what WebGoat looks like and basically WebGoat has got a whole bunch of exercises or lessons that you can go through in various categories. And the idea is for you to explore and just to learn about what the various vulnerabilities are that they're showing. For example, cross-site scripting. How to perform a stored cross-site scripting attack. Let me just make it a bit bigger. In this particular example, it's emulating a bulletin board or a message board system, but if you were to type in something like script, save that, whoops, hmm, okay. That shouldn't have happened. Okay, so I think most of you are probably aware of cross-site scripting, but the idea is just basically that WebGoat is intended to allow you to explore a whole bunch of different categories of vulnerability. Okay, so some examples. How to exploit a hidden field. Why you shouldn't use them. Let me just turn on my proxy control bar and I'm going to intercept posts, which is, as you can see, you've got the option to intercept GETs posts, both of those or all types, all methods. And so if I purchase my HIDEF TV for $3,000, I get the opportunity to intercept it before it actually hits the server and I can see that there is this hidden field which has a value of 299999. I am cheap, as you can see, and criminally inclined, and so I'm going to buy my HIDEF TV for $1. Might seem ridiculous, but a lot of web stores around the 2001, 2002 timeframe actually did this. They implemented their stores using this technique. Say again? Yeah. Okay, so that's a good intro to my next example. In this case, we have some JavaScript client-side validation. We've got a variety of different rules that need to be complied with. As you can see, if I change this in various ways, try and submit it, the validation fires and it won't let me carry on. Just refresh that page. So if I want to submit some data that doesn't match this client-side validation, I can actually just hit submit on some data that does match, that does pass validation, and then send that off. And if the server is not re-performing that validation, then in many cases, I'm going to be able to cause that server to take action on data that it's not expecting. In many cases, you can. For example, if you view the source of the page, you will see there is a validate function which you can override in the location bar up at the top. JavaScript validate equals nothing. In many cases, you can. In other cases, what I'm doing is not considered cheating. The idea is that you need to understand the tools that are available to you in order to perform these kinds of attacks. Okay, so absolutely, absolutely. I mean, there is nothing to say that an attacker is not going to use a Telnet client in order to submit a request to your server. HTTP is text-based. I can use, quite often, I'll make a request against a server using printf and netcat. Shell printf, get slash, et cetera, stashr, stashin, stashr, stashin, partnetcat, whatever, port 80, and it's done. So absolutely, I don't believe that using a tool like WebScarab is cheating at all. As somebody who is trying to defend, you should be using all the tools at your disposal in order to do the best job you can. Okay. Okay, so other examples for SQL injection into numeric and string fields. In this case, we have a simple dropdown that allows us to check the weather at a particular location, cancel that. So for example, Columbia Station 101 has a minimum of minus 10 and a maximum of 102. This is Fahrenheit, it's an American thing. But if I intercept it, I can change this 101, which was in a dropdown, not modifiable inside your browser. Change it to something like one or one equals one. If any of you know SQL, that's going to change it to an always true function and will then return every single row in the table. So just really to show you that an intercepting proxy is a very powerful tool for understanding the underlying request and data that is being sent to the server and to make you realize, or to encourage you to realize, that you need to be performing all kinds of, well, all of your validation on the server side and very carefully for various things. The other part of this exercise is that it changes the request from constructing SQL statements using concatenation, which is really the core of the problem. You're mixing instructions, select star from table, with the data that those instructions are operating on. And so when you've smashed those two together, the underlying SQL parser has no way of knowing which is which. As far as it knows, it's just got a string of instructions to work on. So in this case, the request has now been changed to use a parameterized query, which is a safe form of constructing SQL statements. I can do the exact same attack and you'll see that it's not possible anymore. You'll see how we're now using the sort of question mark placeholder, we're compiling the statement in advance and then inserting the data into that placeholder. And so that generates an exception because our attack no longer pauses as an integer, which is what is expected in this particular placeholder. Okay. Another example, command injection. In this case, sorry, this wasn't the one I wanted. Yeah, command injection is good enough. So in this case, again, we're going to intercept the request. It's passing this parameter to an underlying operating system shell to execute it. In this case, it's calling command.exe and the type command, which is pretty stupid. Normally you're just gonna read it from the file system, but it illustrates the fact that many applications do call out to the operating system to access their functionality. So in this case, I'm going to close a quote, which was placed around this. I'm going to add an ampersand, which also you can use to chain commands together even on DOS and something like, so I'm chaining the extra echo on the end there because I know that I've got a trailing quote character that I've got to watch out for, otherwise it's going to cause me a syntax error. And so when I send that off, you can see my netstat and my quoted commands down at the bottom there. And then another example, these are all pretty much using the same functionality of webScarob, the intercept and modify. It's very powerful functionality, but I'm going to show you something else after this. Again, modify the, change the file. In this case, I'm going to do a directory traversal attack. So I'm going to go up a couple of directories and instead of getting the file in the local directory that I was supposed to get, all of a sudden I've downloaded the Tomcat users directory, Tomcat users file with usernames and passwords and other fun information in it. So really just highlighting the importance of your data validation. Okay, so this is basically what you have in webScarob. You've got the requests which have been made or the history of your conversations. You can filter those for various things. For example, if I only want to see the posts, it'll only show those or including everything else as well. And then as you select the conversation, you can see the details in the windows that are done at the bottom there. So you've got the request on the left, paused out in various ways, and then the response over on the right-hand side. And it's really designed to make it easy to understand what's going on, or if you like, you can see the complete raw data as it was sent on the wire. So now if we decide, for example, that we want to, we've sent this request off and we want to try and change something and send it again. We've got the manual request feature which will copy the request over into this manual request view and we can then modify it any way we like. Maybe we want to include something like, change it to get the boot eye and eye off my root drive. I'll go to my root directory, send that off, and if we scroll down, we should see the details of my boot eye and eye. So it doesn't always have to be done using the browser. Sometimes it's just more convenient to replay a request or to modify it within WebScarab and to send that off. Some of the thing is quite handy. It has a certain amount of built-in error reporting as you type an invalid method. It'll tell you, this is bogus, I don't know what to do with it. All I understand is trace delete options, post head, get and put. As you fix it up, it'll automatically take that error away and enable your fetch button which was automatically disabled otherwise. So this is some examples of how WebScarab NG is a big improvement over the old version. I think it's a lot more intuitive for people to use. The other useful feature is a web services plugin. It's somewhat unreliable at the moment. It's a very new plugin which has just been added. The idea is basically it'll go and download the wisdom from wherever it is, pause it and then construct the XML necessary to actually submit the request to the server and you can put in whatever data you like and then modify that. Yeah, that's actually, for some strange reason, it's just not working today. I haven't figured out why. Yeah. No, no, well, the idea, let me just, I'm going to fire up the old version and show you what's supposed to happen. So as you can see in the old version, there's a lot more plugins than there are in the NG. But if I just copy that URL over, that's interesting. No, no, it's just, I'm sorry. Ah, that explains it. Explains why I'm not getting anything. And I'm probably even working the other one. Let's try that quickly. Yeah, the DOS is actually legitimate. That is allowed, but I don't think it should make any difference, but this should hopefully. Okay, so there are four web service methods which are defined in this wisdom. If you choose, for example, get first name, it takes an integer parameter, 101. And if I execute that, you'll get the response which shows that the first name of user number 101 is Joe. And it's kind of neat for exploring the functionality of web services that are available. Quite often what you'll find is sometimes there are methods that are exposed in the whistle that just aren't expected to be there. Tools like Access2 will just automatically introspect the classes that are exported as a web service and expose all of their methods. So if you don't realize that that's happening, quite often you're going to expose more things than you're intending to. And yeah, that's pretty much what I had to show you. If you guys have got any questions? Okay, so yeah, basically I was saying, there's a lot of stuff that's not yet implemented, things like the spider, the scripting, bean shell, bean scripting framework, et cetera, is not implemented. There's some protocol support in the old web scope that's not been implemented in the new web scope. I don't support NTLM or FNNG. I support SSL client certs and smart cards in old version of web scope but not in the new version. And then the shared cookie jar is just a mechanism for tracking cookies between the proxy and some of the various other plugins. So some future directions, some things I'd like to add. An identity module which automatically associates the identity of the user making the request. So once you've logged in, you can associate your identity with that particular session identifier or it can be extracted automatically from the basic authentication credentials perhaps, from the client-side SSL cert. All that sort of information can provide an identity and it's useful to be able to track the identity across a whole sequence of requests. And that will support things like reverse engineering and access control matrix in your application. So if you log on as one user, see which things you can access, fire up the spider and track down all the links that that person can see. Do the same thing for a different user, maybe an administrative user, and then see if your unprivileged user can still access those links that the administrator can do. Then it'll show you that you're doing things like presentation layer access control, where you say, well, I'm not going to show you the link if you're not allowed to access it, but if you know what that link is, I'll still allow you to execute the function. I think you can see that that's a bad idea. So that sort of functionality in WebScarob would help to expose that flawed logic. The classic version of WebScarob has a random session, random generator quality assessment tool, checks the sampling of session identifiers, and checks to see how random they are. The old version is pretty, it looks cool, but it's pretty badly flawed. New version will perform proper random analysis, kind of like Michelle Zalewski's Stompy tool, which is a very cool tool. And then things like re-implementing the HTTP client. For a tool like WebScarob, you really want to have complete control over the HTTP protocol so that any conclusions that you come to with regards to how the client behaves when it receives something from the server, or how the server behaves when it receives something from the client, is not unduly influenced by the tool that you've placed in between them. Because in many situations, if you want to extrapolate this to the broader internet, they're not going to have the tool in between. So you want to make sure that your conclusions are valid without the tool. And in some cases, apparently, things as simple as the number of spaces between the colon and the header and the value can actually make a difference. I haven't encountered those myself, but one of my users has complained. And so if you want to try it out, you can run WebScarob. It's available using WebStart. There's the URL. Join the list. Host it at osp.org. You can access the source in a Git repository on my server, and then clone the repo, build it using Maven 2, and let me know how you're doing. And now, if you have any questions, I'm all yours. There was an attempt to build in some automation functionality into WebScarob.ng as part of the recent spring of code. The person who was trying to implement that never actually got anywhere. It really depends what you mean by automating the tests, though. Okay. Okay. Right. At the moment, no. Short answer, no. It's something that I'd like to add because I think it would be valuable. If you have any ideas as to how it should be presented, now how would you like this to work? Please, let me know. And if I can get my head around it, I'll build it. Anyone else? S.P. Nego with Kerberos? No, I don't. That is pretty tricky to get right. The funny thing is it will actually work using IE because you can proxy S.P. Nego. So you'll see a 401 come back. The first time you make the request, you'll get a 401 unauthorized with the handshake details. Your browser will then perform the necessary handshake. So every second or third, or so to say, two out of every three conversations will be negotiation, but you will actually be able to see and intercept the request. It'll be tedious, but you will actually be able to do it. You just won't be able to do things like the manual request replay because WebScare itself doesn't support it, but it will allow it to be passed through. Yeah, you'll see the token going backwards and forwards, but yeah, there's no insight into the content of the token. There are some S.P. Nego Java libraries, not freely available, though, as far as I recall. The JSIFS project was working on implementing S.P. Nego. I don't know how far they've got. Last time I looked at it was a couple of years ago. I've actually never ever had to test against an S.P. Nego server. Anyone else? A lot of them are very active. The New York chapter in particular is I think it's our largest chapter, I think being in the financial district and so on. They've got something like 250 active members. I mean, that's incredible. Our OWASP conference that we had in San Jose last year had around 250 people and they get that on a monthly basis. That's very, very impressive. There is a local OWASP chapter. The chapter leader is a guy named Sebastian Dalierschneider. And they're pretty active here as well in Brussels. Yeah, the details are all available up on the OWASP site. And you can get in contact with Sebastian and whoever else is busy in the local chapter. Yeah, the local chapters, I didn't think I gave you a chance to look at this, but that's basically flags where there are local chapters around the world. So it's pretty extensive. I think there's quite a lot here in Europe and Asia and America as well. We don't have training as such. One of the things that we've tried to avoid is getting into the training, the certification kind of things. We've provided a whole bunch of material that the SANS organization does perform web app sec training. And my company performs web app sec training. So maybe there's a bit of a conflict of interest in that sort of thing, but there is some discussion on the OWASP leaders mailing list at the moment about certification. And I think so far the consensus is that it's something we don't really want to get into. Anyone else? Great, thank you very much.