***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.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)

***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!

This month I want to dig a bit deeper into the cross-site scripting (XSS) attack. The type of issue is rather pervasive out there in the wild, and most web site developers have no idea what an XSS is and how to fix it – until their users are getting hurt. The sad truth is that many web sites do'’t pay as much attention to XSS attacks because they aren't used to compromise the web site's data.

These attacks are used to steal information from the browser of the user, making them perform unauthorized scripts because they believe the website they are visiting is trusted. It's a nasty attack and relatively easy to detect, though harder to stop. Let's jump in.

What is XSS? How does it work?

A cross-site scripting attack uses an unsuspecting web site to launch an attack against a visitor, leveraging the "trusted" nature of the underlying web site. When the visitor's browser renders the compromised page, the malicious script, which is stored on another site (ergo CROSS-SITE), is executed providing access to information resident in the browser of the visitor.

XSS comes in two flavors. The first, called a "stored" attack, involves the offending script command to be entered into a text block. This could be a comment field, search box or message forum, etc. This can be a problem for any of the "Web 2.0" types of applications that allow user comment and feedback. If it allows visitors to insert and store data in your application, then it's vulnerable to a stored XSS attack.

The other type, "reflected XSS" involves more traditional social engineering. The visitor needs to click on a link, which has the malicious script embedded. The web site then "reflects" the script back to the visitor and it’s executed in the visitor’s browser.

What is the impact of a successful XSS attack? Who gets hurt?

Basically, the user gets hurt, not necessarily the web site, and that's been the big sticking point in taking XSS attacks seriously. The first generation of XSS attacks really focused on nuisances like cookie stealing, but more recently a new type of very malicious XSS is appearing. These new attacks can bring down web sites, cause users to take actions like they don't want to (like the Samy MySpace worm), and even host a phishing site within a real site.

To illuminate a bit on this last example, imagine that you are buying something on yourfavoritestore.com. So you go to their web site and everything checks out. The SSL certificate is right and the domain is right. You're good, right? Wrong. What happens if you enter in your userID and password and it turns out a malicious script in a comment field on that page launches a script that takes the data from your form and sends it to Eastern Europe? You'll never even know what hit you.

It's like an ATM attack where the bad guys bolt a fake front on an ATM machine. The fake front reads your card and then passes it to the real ATM machine. You get you money, like you expect – but the bad guys have your number and your PIN. XSS can do that, but a lot more transparently and with a lot less risk to the attackers. No wonder this attack is very prevalent.

Detecting the XSS

So how to you detect a potential XSS problem? Technically it's not that hard, although the scale of the problem is significant. Basically you have to check every form and field in all of your web sites. Anywhere someone can enter text into your web site needs to be checked. Obviously that's a tall order for a human, so you are best off looking at scanners to help automate the process.

How to fix the XSS?

Fixing the XSS is also readily doable. Here are three options to consider:

1. Web application firewall – Yes, a WAF will help to block if your web site calls out to a foreign site to execute a script. So if you front end your application with a firewall, you can largely eliminate the problem. Of course, all your traffic needs to go through that firewall so make sure there aren't alternate routes into the application that could get around the defense.

2. Code frameworks – A number of the packaged application frameworks are down with XSS, and have built-in validation processes to make sure that forms and fields cannot accept foreign scripts. Microsoft (once again) is leading the business on this issue, with ASP.net offering many of these advanced validation checks built-in. J2EE and Rails offer a lot of tips and documentation to defend against XSS attacks as well.

3. Developer training – It's great that a lot of the frameworks add defenses to stop XSS, but ultimately you want your developers to be aware of the attack vector and to code their applications with these issues in mind. Of course, we are a ways off from developers caring about security, but through consistent evangelizing and persistent testing of applications, you can get the developers on board.

XSS is a scourge, but a manageable issue. With a little preventative scanning and some proactive mitigations, much of the risk of XSS can be eliminated from your web sites.

Posted by pschooff in | Permalink | Comments (0) | TrackBacks (0)