We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

The Mike Rothman Security Report

Peter Schooff

The Scourge of Cross-Site Scripting Attacks: Mike Rothman Talks With Jeff Williams

Vote 0 Votes

***Editor's Note: If you're interested in the secure B2B identity architecture of tomorrow, make sure you sign up for the Federation and User Centric Identity webinar today!

Listen to or download the 9:55 minute podcast below:

Download file

In this podcast Mike talks with Jeff Williams, CEO of Aspect Security, where they discuss everything you need to know about identifying and defending against the current scourge of cross-site scripting attacks.

MR: My friend Jeremiah Grossman over at WhiteHat Security actually has done a bunch of research that says upwards of 60 to 70 percent of websites are actually vulnerable to cross-site scripting attacks. So I'm very pleased this month to actually have lined up one of the preeminent experts on all sorts of different application security issues here too kind of explaining cross-site scripting, talk a little bit about how it is that developers can both address as well as make sure that their applications aren't vulnerable to cross-site scripting attacks. And with that, let me introduce Jeff Williams; he is Chief Executive Officer of Aspect Security. Jeff, how are you, buddy?

JW: Great. Hi, Mike.

MR: So hey, why don't you just kind of introduce yourself and Aspect Security for maybe a minute and just give people a feel for what you guys are about.

JW: Sure. I'm the CEO of Aspect. We're a small company. We provide application security risk management services. We also have some training courses and some services to help companies start writing better code across their whole STLC.

MR: Yeah.

JW: I'm also the chair of OWASP, which is the Open Web Application Security Project and which is a not-for-profit foundation focused on application security and I encourage everybody to go check it out.

MR: OWASP.com is exactly right. That was one of the things you were going to talk about a little bit later. So if you would, why don't we just kind of go over and give everybody kind of a pretty brief introduction to cross-site scripting and really why it is such a problem out there.

JW: Sure. So the underlying problem is really very simple; its developers are taking input from untrusted sources like the HTTP request and they're sticking it into their web pages without any kind of validation or encoding. And what attackers can do is they can send in little fragments of scripts to an application. The script gets echoed back into the HTML pages and runs in the victim's browsers.

So at the end of the day, it allows attackers to run scripts in the victim's browsers. And JavaScript is a full programming language. You can write very complicated applications in JavaScript that do things like steal data, and steal session cookies, and accounts, and all the stuff that you would put into a Web browser so that's why it's a serious problem.

MR: Yep. Do you buy this number from WhiteHat in terms of 60 to 70 percent? I mean when you kind of go into a new client's site and really start checking out what it is that they have, is this kind of the most prevalent issue that you find within their web applications?

JW: Well, it's definitely incredibly prevalent. I actually think the number is probably more like 90 percent. We almost never see an application that doesn't have some cross-site scripting problem in it; some of them are more obscure. Most of them are very easy to find, even a tool could find them. But they're not the most serious issue. I mean they're definitely important but in terms of impact, they're probably not the most serious.

I would put access control issues, authentication issues, in terms of impact as higher but there's no question that cross-site scripting is the most prevalent issue of application security.

MR: Yep, which actually brings up a good point. Obviously, there are things that are more serious. But what are some of the stuff? So you talked about JavaScript as being a full programming language, what are the things that attackers could do if they were actually able to perpetrate a cross-site scripting attack and actually gain control of the user's browser?

JW: Now, when you authenticate with a Web application, you type in your username and password, and the site issues you a session cookie; it's like a temporary hand stamp that you might use to get in. And if the attacker steals it, they can become you, it's just as good as stealing your username and password. And JavaScript has access to the session cookie.

So if an attacker can perform a cross-site scripting attack, they steal the session cookie, and then they just become you. They can do anything that you can. Now, another thing they can do that's with cross-site scripting that's even more serious is they can inject what's called an "XSS proxy" into your browser, which accesses applications as you.

So the attacker is actually using your browser as a proxy to browse the Internet as you; so sending out requests through your browser and then go to sites that trust you. So they're using you as that trusted man in the middle and using your credentials to access sites and you might be totally unaware that any of this is happening.

MR: Yep, which could clearly be our problem. So obviously, it's something that might not be the most serious but it's certainly something that we want to address because it puts our users at risk, or our customers, if you're in some kind of e-commerce type of application. So if you had to say that there were one or two or maybe three things that developers can do to kind of avoid this issue, what would they be?

JW: Well, I mentioned at the beginning, the underlying flaw is that they've failed to validate their input and do the appropriate output encoding before they put that input into a webpage. So there's a bunch of different approaches to that, but really anytime you get anything out of the HTDP request, like a get parameter, or get header, or get a cookie. Anytime you get stuff out of the HTDP request you autovalidate it, and I'm talking about white list validation; not just checking for a view bad characters because that's not going to get it done. You need to check if it's a zip code you're expecting it should look like a zip code.

So put a regular expression there or compare it against a list of known good values, something like that. And then for output encoding, anytime you deal with an interpreter, you want to do the appropriate output encoding. And for HTML that means you want to use something like called "HTML Entity Encoding", that's when you replace like the less than symbol with "<" and a bunch of different characters like that.

You should encode everything that you're not really sure is safe for the browser, that's all the special characters, anything that isn't alphanumeric you should probably HTML entity encode before it goes into the browser. Don't do a black list encoding where you're just encoding three or four characters; we see that an awful lot and it's dangerous because attackers know how to bypass those things.

MR: Yep. Yep. And so it's really one of these things where it continues to be a kind of a arms races where you can do the output encoding and that certainly helps, but really the white listing approach is kind of interesting to me because, again, what you're trying to do is only specify what can be allowed on your site and within the application as opposed to kind of looking for known types of attack vectors. It just seems to me like a much more leverageable and strategic way they go about building your application.

JW: That's exactly right. The black list approach means you're going to constantly have to maintain the black list and add new characters as attackers develop new techniques. The white list approach, if you say it's a zip code, and its only five digits or five-four, it's like that forever. You're never going to have to change that definition so it's actually much more efficient long-term to just do the work and do a positive security model for your validation.

MR: That's exactly right. So Jeff , I want to thank you for kind of the little primer on cross-site scripting that was certainly valuable to me and I know the rest of the listeners here at ebizQ's network. So what we always kind of end up at the Mike Rothman Security Report with a little session I call "Free Association".

So what I'll do is I'll blurt out a statement or two and I just want a real quick top of mine one sentence or less type of approach from that standpoint or answer. And again, we're just kind to try to have a little bit of fun with this but; again, I do think that it is pretty instructive to understand kind of some of the top of mind issues are. So you game for that?

JW: Sure, let her rip.

MR: Okay. Great. First thing I'll ask you about are application scanners.

JW: Pretty good at finding cross-site scripting flaws, not great at finding a lot more, but probably should be part of your balanced breakfast.

MR: Great. What about the SDLC?

JW: If you want to do application security right, you got to get in your SDLC. I strongly recommend getting organized and maybe thinking about building the process around an enterprise security API. I just started a new project that OWASP about that. You can find it at OWASP and the project name is ESAPI.

MR: And that's great. Let's just kind of wrap up a little bit with OWASP. So in one sentence, again, why should folks get involved?

JW: It's a huge free and open community dedicated to application security. we've got a zillion documents, a bunch book links, PDFs that you can download for free, and a ton of great tools, some of the leading application security tools including WebScarab, which is a testing tool, and WebGoat, which is a full application that you can use to learn how to test application security.

MR: That's perfect. I want to thank Jeff Williams from Aspect Security; that is aspectsecurity.com. Is that right, Jeff?

JW: That's right.

MR: If folks want to go find you. Go check them out. Again, one of the preeminent experts on kind of Web application security out there. And again, this is Mike Rothman. Appreciate everybody listening in to the Mike Rothman Security Report and we will see you next month.

ebizQ is proud to bring you Security Incite's Mike Rothman, who podcasts and writes on application security and related topics.

Recently Commented On

Monthly Archives