 I've been working on web applications security for about three years, some of the things I've seen, how to get into different systems on a purely web application level, not the web server, more like the CGI's on top of it, so just briefly go over what a web application is. Basically a CGI, there are message boards, web mail, guest books, auctions, online banking, stock quotes, the biggest companies run these things, they're everywhere. If you go on the web and do just about anything, chances are you're working on a web application. What, as your security folks, do we see and how to break them down, how to circumvent the security in them, so that's what I'll be covering. So the scope of the topic I'm going to try to keep to on the client side of the connection, web application security does deal with the actual exploitation of the system, however RFP or many other people cover it a lot better than I do, so this is sticking to basic client level, attacking the browsers, attacking the cookies and things of that nature, however if you guys have like system things you want to ask, quote very, also if you guys have any questions, any time, go for it. So who uses web applications? Eve, Yahoo, Microsoft Hotmail, eTrade, anybody got some more? What was that? Right, there's a web application too, like say, like leaks, this, routers and stuff like that, that would be a web application. Right, at least distance learning and things like that. Right, right, right, like all advantage or something or, not sure exactly what I followed, but if you have questions on it. Parasites, okay. Let's see, from a security standpoint when you're auditing a system or I'm attacking a system, generally there's three main types of what I'm trying to profile a system as far as learning about it and what I'm trying to do. There's the CGIs or the web applications that allow the user to input HTML and get an echo of HTML back where it means it might be filtered, but it still comes back as HTML, it's actually allowable, seen in chat rooms and message boards and things of that nature where it stays HTML. The other ones are the ones that do not allow HTML at all, the ones that strip it out blatantly for whatever reason, you know, we'll figure out why later. And the other ones are systems that use their own subset of HTML, I won't cover this too much, but you'll come across like chat rooms and message boards and stuff like that where you want to change the formatting of the web application, you have to use their own subset of tags and there's also the ones I'll briefly cover on the ones that use Java based engines to run it. The chat rooms like, you know, Java based client that connects to IRC or something like that, there's a lot of them out there, but I won't cover those too much because they're kind of their own embedded app. So when you have a CGI, what kind of things are you exposed to by putting it up on the web where everyone can look at it? There's system exploits on the system itself, you can, there's browser redirects for the user, if you can find it and implement a CGI bug, you can throw an entire site to another site, say a portal site, that'd be kind of fun. There's page spoofing where we see instances of a bug being exploited in a system where the user gets a fake login page and the end-with-the-link give up their username and password. There's also depth of their cookie file on that domain which could give up their authentication for that particular session. And there's also things you can get user information and you can also track the user even though it's not really your site. So we can cover, anybody have a question so far? I'm sorry, what was the question? No, I'm just, no it's from myself. Okay, first we'll cover the systems that allow HTML. Let's sit here. Let's go over the basic cookie security because a lot of sites, they use cookies for simple authentication and re-authentication as they move through the sites, also like for shopping carts and things like that where the cookie actually keeps track of the actual session. Basic cookie security is a particular website should not have access to any cookies or only should have access to cookies for its particular domain. It shouldn't get access to cookies from another domain. However, nice people at Microsoft with that latest IE bug kind of destroyed that one. But basically that's the security implementation. So let's say you found a, what is JavaScript now? What does JavaScript have access to? JavaScript when you're implementing it to the system into like a chat room or a message board or something like that, what does it actually have access to? Well, it has access to all the browser information, it has access to the IPs of the user, all the plugins and the paths to the plugins, just about everything that they're using, it also has access to the cookie files and their environmental variables. The important one that it has access to, the domain that JavaScript is executing on, it has access to the cookies on that domain. Now the trick would be for a supposed hacker or malicious user is to try to get the user's cookies off the domain into another domain. Okay, so I'll show you how a lot of, how that's accomplished. How that is accomplished is if a user was to put HTML and JavaScript into a message board and you were to go read that message that JavaScript would execute in your browser environment, okay, it would be able to grab the domain cookie string and append it to some HTML mechanism that would send a GET request off the domain to somewhere else. For instance, you could change the source of an image on that page and append it to the end. So a GET request would go to another server off the domain and you'd get the actual cookie string. I hope that's like clear. Okay. Anybody have any questions on this? I know what I did get clear. Yes. It's okay. I guess it would, the flaw would lie in JavaScript. Okay. If you're able to put JavaScript into a system and users would read it. Okay. If a user would read it, the code would grab the string and say, make it real simple, open a new window with the attackers domain and append it with a CGI and append the cookie data to the CGI variable. So it would do a GET request with the cookie value off of the CGI. So basically the whole cookie value gets passed to the CGI off the domain. That's for authentication. That seems to be one of the more widespread ones. If you're able to get the users cookies, you can replace your cookie with theirs and in essence become them. So if an active eTrade user was running, grab their cookie file, replace it with yours and guess what? You get to trade stocks in their account. So now in a lot of systems, they'll have, I guess, HTML JavaScript filters to try to clean up the problem, but still have to allow, I don't know, for whatever, formative reason to keep HTML and JavaScript in this HTML itself for their users and features. So I'll talk about some of the ways to get around it, how you test it. The basic, basic, basic tags, when you're running off CGI, what you don't want to allow into your system to be able for the user to pass into the message board are the following tags. You don't want to have the P tag going. I'll explain these why later. You don't have the applet tag coming in. The embed, script, layer, frame, set, frame, HTML, body, style, meta, or object. There's a lot of them you have to filter. If you allow the applet tag into the system into a system that allows HTML, they can load whatever Java applet you want and do whatever to somebody else's domain. Imagine if somebody, like Microsoft Hotmail, you email somebody a message with an applet and it loads, and then you have access to everything on their domain with a Java applet. The same thing goes for the style tag, embed, anything of that nature. So those tags you actually have to strip out even though you allow HTML. Nothing good can happen when you're using those tags. So the script tag, the P tag. There's a known exploit that's been posted to BugTrack. I think George Iginenski found it where you can actually add a VB expression that actually execute JavaScript without actually having any JavaScript looking things in it so nobody knows really to filter for it. You'll find it on BugTrack and things like that. Which brings right into the things that you can check in your own CGI's or other people's CGI's. I'm sorry. The question was, do I think that more security should be in place for say forms of values being passed to the CGR to the web server as far as should it show you what you're actually sending them? I think yes, but no one's seen it so far. Basically I guess the idea of the web is trying to make it user friendly. But yeah, I think so. I'd like to be able to know immediately what cookie data I'm sending without actually having to look in the cookie file. That would be my preference. So when you're testing a system, if you're actually auditing your own systems or somebody else's systems, what can you actually test against what actually are the exploits to get past the, I guess the string filters and things like that. One very simple one is the script tag. Everybody should be familiar with HTML and JavaScript. The actual script tag, when you put an expression in there, you submit it to the system. You can even try it like a lot of search engines will allow you to put right into their search function, put a script tag in, and it brings back a script tag and it executes major no-no to have on your major site. Another way to, so what major sites do is they filter for the script tag itself and they'll strip it out, replace it with whatever, they'll strip it out completely or replace it with something, which is a good tactic that you should all use. Another way to get around that would be to when you're submitting to the search engine itself a string, instead of just one singular line, throw a carriage return in it because it's actually a character and it'll actually, a lot of times beat, they won't escape the carriage return, so it'll actually beat the filters and still get by and echo back. Let me show you. Okay, you see the script tag way up there? That's the most basic one. Try that into a lot of places and that will work. So basically what you can do is if you know somebody's active on a session, say anywhere like on Hotmail or something like that, you email them, I'm not saying it works in Hotmail, but you email them an HTML mail with the script tag in it and it executes. You have access to everything that Hotmail actually has access to. The second one from the top is I call image sourcing. Basically what the idea is the JavaScript colon and then the JavaScript expression will actually execute inside of Netscape and run. It doesn't actually look like JavaScript, but it actually works, so sites will have to look for the JavaScript keyword and like separate it somehow or do whatever they want to do so it doesn't execute anything other than what it originally looks like before it gets echoed back to the user has to be done. In the ones below it where actually Netscape's code names for JavaScript are developing it, Mocha and LiveScript and Replacer JavaScript will also work which is quite nice of Netscape to not to tell us about. So basically those in all systems that allow HTML have to strip those out before they get echoed back to the user otherwise security breakdown again. The singular line break below that is what I was talking about before that will still execute in Netscape and beat a lot of filters. The multi-line break so trying these against systems they'll get smart and wise up and start escaping the carriage returns or you can multi-carriage return and it still works so you escape the whole thing so we begin to start to see the thing where HTML and JavaScript start not to look like HTML and JavaScript it looks visually broken but it still works so you still have to clean it up before it gets echoed back to the user. The one just below it HTML entity string break there's one that's an HTML entity that's like a weird character you want to display I'm sorry you have a question? I haven't seen any commercially available ones most companies that I deal with have been writing their own for their own developers which means that they want to strip things like this out they'll write their own libraries and have all user input variables filtered through them and then they can use them or they just blatantly rip out every instance of HTML I haven't seen any commercial products that do this so everybody's kind of on their own until someone figures one out. The HTML entity string the ampersand pound sign zero nine semicolon is just a I think that's like a tab or something in ASCII and the whole ASCII set is available in Netscape so you can make all the weird characters show up but I found that that particular string 9 through 12 actually breaks it up and will still execute settle bypass the implemented filters once again so things like that will work what happens is when you throw that into the system and you know you use source on it that will actually not look like that but it'll be separated but still work This requires a greater than less than what if they just strip out the group? Right, that's the most effective way I've seen so far on a system that does not want to allow HTML into the system you rip out this less than and greater than science and also the quotes and you lose all HTML functionality and security back Do you still have the application allowed to continue on the system? Yes you will so most chat rooms measure the boards to allow that yeah the one just below it HTML entity I did have to figure out why this works but I found it one day and it works the hamper send I guess open curly brace and it has to be perfect for it to work and it only works in Netscape the hamper send curly brace open has to be filtered for otherwise JavaScript will execute any expression that you throw in there so it might be a good one to remember because it's posted out there but it's hard to find oh sure, she asked me to repeat the question before I answer sorry okay when I'm auditing a system that what I'm generally looking for is I'm looking at the URL I'm looking at all the source code in the web page, looking at all the form values looking at all the link URL values anything that has a CGI and all the variables to it and seeing what values it's taking if it's taking any and shopping carts are notorious for this when you're buying an item it'll have price equals and then you submit so it stops me from 3,000 I'll just make it 5 bucks many, many sites put this in there and trust the value that I give it and I bought a laptop for $5 I didn't get that question take the fifth also all the strings a lot of times developers will put strings inside of URL variables and stuff they actually get thrown up on the page for instance like ads and things like that a lot of times they don't filter those and see what actual variables are getting filtered and what aren't you know you can change it to anything change it to JavaScript HTML HTML put a negative 999 in there and crash the CGI many, many things also what I had to mention is many CGIs when they're doing authentication for the users that aren't using cookies, they use a login equals and like for portfolios and things like that so if you actually just change the login to a different username you'll get their portfolio don't do this people are looking now basically you've seen a lot of the exploits there are more but as of yet no one's put out a good security auditor yet I've heard rumor of them but I haven't seen any of that good so how to protect and defend do not trust any of the input that the user is going to give you don't care if it's the browser information their username and password do not trust anything that they're giving you check everything, strip everything because people are doing this for a lot of free time and testing every single value they could put into every variable and to see what your CGI does so you have to account for everything one rule of thumb when you're developing a CGI never, ever, ever allow JavaScript, Java or any plugins that your site didn't create onto your system so that means is if your users are able to put JavaScript, Java or a plugin on your system you've got to disallow it because do very bad things, for instance like Flash has JavaScript in it as far as like a sub-language with Lingo and they have full JavaScript functionality from inside of Flash so you might think I've got everything all blocked and you're allowing them to use Flash and all of a sudden your whole entire user base will have to do somewhere else also if you're really security paranoid and you're running like, say business.com and you have to allow some of these things to go through and you're really paranoid that you're not going to get everything right like say for your message or your chat room you want to keep pretty good security for the cookies themselves hosted on a different top-level domain hosted instead of like business.com go through business.net for a moment until you move them back to business.com it's a method I've seen work pretty effective in the past again somebody asked the question how to defend if you're in a workgroup type environment create libraries to do HTML stripping that all your developers can use and funnel all the user input variables through and get them back out so they know all the variables are safe to use in the user's environment and out of the user's environment and also one more authentication scheme that I've seen a lot of people use is when you're doing a cookie-based authentication and you're doing a session ID with your hashing the user in the password with a random variable or something you can actually rehash another variable let's say in a form submittal you put a hidden variable inside the form that you're submitting to the CGI that means no one else is going to be able to submit the form off of your site that's quite clear it's kind of like tagging the web page of sorts well let's say I'll use Hotmail for instance let's say they're doing a session-based ID session-based authentication and you don't want people logging into Hotmail from places other than Hotmail so what you would theoretically do is run a hash on their cookie that's in their system and tag it as a hidden variable inside your login page that way if you move it to somewhere else and try to submit again with different values it will fail because the hash won't match the hash has to be server generated unless it defeats the purpose sure yeah the question was you'll pass different or multiple variables off pages as you go through so it's important to check every single variable as you're going through the site so basically you have to crawl the whole site and be thorough any other questions? the question was what I feel that this is a problem of I guess lazy developers not doing correct string matches or not being very security conscious in general basically I would say yes and no one I would say yes they're lazy programmers they're not looking at bug track or the other sources for the known exploits to know they aren't because they don't know them all so they can't filter for something that they didn't know existed yes it does that's why HTML email pretty much exists I'm sorry he asked does HTML mail execute JavaScript yeah it can you'll see in the news all those Hotmail exploits and stuff like that those I haven't played with firsthand but problems with those probably could and do exist any other questions? I know of like a couple but I wouldn't classify them as good yet they're looking for basically the tools that I've seen are looking on a commercially available applications most bigger systems where these are going to be needed the most are not something that you can write an immediate big software package for because they're proprietary and you have to do it manually now unless somebody comes up with something pretty good and I haven't seen that yet no basically you would his question was about defeating the hashing you hash a variable like something random on the page and also part of their session with only a hash that you possess you have to keep your hash kind of private you have to do it that way you have to use something on the server side that only the user has and the site has so it has to be done well I probably not explaining it well as like applied cryptography would but you can hash the page and have it work well well that's the idea that's the idea of hashing you can't go backwards at least I can any other question? if you turn off the this question was if you turn off JavaScript and Java will the image sourcing one work no it won't get all JavaScript is pretty much turned off but that makes for a pretty lousy web environment and everything breaks on the web those who have run it have seen any other questions? alright yes that's it thank you how hard is it what a hell I feel about crypting the browser session and or the data being passed right I would say I would like it all encrypted however I guess the the RSA licensing gets pretty expensive from time to time I mean you have to get a license for every single server so it gets pretty expensive that's why they only do it on purchases and stuff like that but I would like to see all of it but we don't have it yet but even if this is encrypted this is not stopping the fact at all because the data on the client is not there right yeah basically he's talking about client side client side signing is he can claim to be whoever he wants and there's no checking on the client side end so yeah also actually I didn't get to ask Jennifer Granik one question I don't know if she's here or not but basically I wonder if the source of the web page would fall under unauthorized access of the source code of an interpreted page or or I guess fall under reverse engineer that did the DMCA would I be in the source code of a web page fall under that I don't know maybe and this is any other question that you said oh I'm sorry there well let's say I guess some people want to direct traffic away from your site to somewhere else and they post something on your site that means all your visitors that go to your site get forward to somewhere else that would be one other thing if they can't well if you're the only one posting the information on your site then you're pretty much clean that means everything that you do is your fault so alright the parent friend he's actually not a way to hide the URL if I know any ways I haven't seen any really good ways to do it I say the parent frame technique works quite well I haven't seen any other really good ways I have seen begin to load a page and then stop the load and then he kind of gets a URL that way but I haven't seen any really good ways that's kind of weak the question was you can actually yeah I forgot to mention that one's a pretty good one a lot of I guess browsers and search engines will take not only ASCII as a domain name but you can actually or like IP addresses you can actually re-encode them in URL encode and get those to work or you can get hacks to work I've seen octal work and everything like that so those are actually good filter passing mechanisms the question was using hidden iframes yeah hidden iframes you can use hidden layers and do it that way so again don't wow people putting layers on your page bad news the p-tag sorry I don't have like the perfect syntax memorized to type it out for you however I guess in VB script there's a left colon expression you can search for that under the p-tag I think Georgi Geninski on his site has it posted but it's a VB script that will execute also style has one similar like that on a style tag you have type equals and you can put javascript and stuff in between it in between the beginning and style tags and once again javascript into the system javascript's pretty much a cockroach you have to exterminate I'm sorry I missed that I really don't have no X in all that well but from what I read from the specs it seems it's like for instance the ones that are broken to the visually don't work under XML because it's very specific meaning that programming is not forgiving when you make a mistake so any other questions what time do we have close though that's all I got so