TPR5: Cross-site Scripting: What Is It, and How Can You Protect Your Site from Becoming a Victim?

[Intro Music]

Announcer: You’re listening to one in a series of podcasts from the 2009 HighEdWeb Conference in Milwaukee, Wisconsin.

Paul Gilzow: Hi, well, my name is Paul Gilzow with the University of Missouri, Department of Web Communications. If you�d like to get a hold of me afterwards, it�s pretty easy, actually, do a Google search for Gilzow. I�m pretty much the first four or five links which you can hit me at either Gilzowontwitter or Gilzow@missouri.edu. Before I get too far into it, I would like say thanks to Michael for telling me about Precy and also my graphic designer Josh Nichols back at work for helping me with the presentation design. He�s the one who decided we should go with the 80�s retro video game theme and do some space invaders.

So real quick. How many of you in here have heard about cross-site script? Good. Almost everybody. How many of you have a pretty good idea of how it works? A couple of you in here. All right. How many of you have used it to actively explore the website? OK. The FBI would like to meet you after the presentation. All right. How many of you have done a JavaScript development? Good. Good chunk of you. How about HTML development,at least? OK.

So we�ve got a fairly diverse population here with experience so �what I thought I�d do is start at the base, build up from there to make sure everybody is coming on the same level playing field. So all of our browsers �just talking about browsers real quick � all of our browsers adhere to what�s called the same origin policy when it comes to JavaScript. What that means is JavaScript is only allowed to interact with other JavaScript and other pages that all come from the same origin.

That means the same domain, the same protocol and the same port and they should make sense. Obviously, if you�ve got Facebook or Twitter up in one browser or window or tab, do you want it to interact, let�s say, your bank that you got up in another browser or tab or another window.

You want those two to be able to interact with each other. No! No! You don�t want those to interact with each other. So that�s what that same origin policy does. It says, �All right, you cannot jump over out of that same origin into somewhere else to interact. You have to stay within the same origin. Cross-site scripting note seems to bypass that same origin policy through injections.

What I mean by injections is anywhere in your site that accepts user input, the attacker tries to slip in commands that hopefully the server will send back out to the browser because if the server senses it, well, then it�s from the same origin. Right? The sever senses that information back to the browser. It is from the same origin. So it�s attempting to bypass that same origin policy through injection. It usually happens in a form of one or two ways, either HTML code or you�ve got something like an image tag and they set the source to JavaScript or through an actual script element, where they�ve actually said, �OK. Go out to a whole other site and grab this JavaScript file.�

Now, cross-site scripting is not an attack against your Web server. It�s not even an attack against your website. It�s an attack against your Web users. What it does is, it attempts to exploit the trust that your users have for your site. It�s also usually an indication of a match larger problem. If you�ve got cross-site scripting vulnerabilities, there�s a good chance you�ve got other vulnerabilities�cross site request forgery, sequence injections, et cetera.

All right. So we need to talk about how big of an issue this is. I had hoped after last year�s presentation � I gave this last year � I�d hoped that cross-site scripting issue will be a thing in the past and I�ve got nothing to talk about. Instead that�s not the case, it�s actually even worse. ��So some quick stats real quick.�

In 2006, WEB Act Sec stands 12,000 sites; of those 12,000 sites, almost 70% had cross-site scripting vulnerabilities. On the 2007, in 2007, they scanned almost 33,000 sites found almost 70,000 vulnerabilities and out of those 70,000 vulnerabilities, almost 60% were cross-site scripting.

Unfortunately, I can�t find any statistics for 2008 or 2009 specific to cross-site scripting. But you can see in 2009, the State of Affairs just as far as security on the Web has gotten worse. In the last year, there has been a 671% increase in the number of sites that are currently sending out malicious content.

Huge increase. In addition, this went down here 61% of the top 100 sites are either hosting malicious content or contain a mastery direct, one of the things that you can do with cross-site scripting. All right. So it hasn�t gotten any better, unfortunately. So what are some of the danger in cross-site scripting? What exactly can an attacker do? All right, again, it usually just the first step in a large attack.

I can take a cross-site scripting vulnerability combined with another site that has a cross-site request forgery vulnerability, which we�ll talk about in a minute and combine those two to be able to replay attacks that can lead to identity theft or spam or phishing. We can de-phase sites. It can totally change the way they look. I can load my JavaScript into a pace and suddenly you�ll said that you�ve done some JavaScript development. If I can put JavaScript on a page, what can I do to the page?

Anything, right? How many of you were in the JQuery recession earlier? OK, so you saw some of the things that you can do with JQuery. Right? Well, if I can get an injection, cross-site scripting injection in there, I can load the JQuery library, in addition to loading all my scripts. And not only can I just use my own script, I can use JQuery to even make my script unique, even easier so all kinds of things that you can do.

Use a framework to help me out. One of the big problems is that it�s platform independent. It doesn�t matter what OS it�s on. It doesn�t matter where it�s at. Anything that can run a browser that can run JavaScript is vulnerable to these attacks. All right. So because of that, it can spread much faster than traditional viruses.

How many of you remember to Samy worm that hit MySpace a couple of years ago? �It was a cross-site scripting worm that spreads throughout MySpace and infected over one million users in less than an hour. �No other virus, no other piece of malware has spread that fast. And think about how dangerous this has been.

How many has a cell phone that has a Web browser? Almost everybody anymore. Everybody�s got one. I was at BestBuy there was a refrigerator that has a browser in it that runs JavaScript.�Yeah, so there�s a coffee maker that hooks up and has a browser in it. I don�t know why but it has one in it and it�s vulnerable to cross-site scripting so anything that runs a browser.

And I don�t know if you�ve heard there has been a lot of talk in the last six months or so about the browser becoming the next OS because we�re running so many applications inside the browser. That�s good in one aspect because that means your applications are available anywhere in the world. �All you have to do is get to a browser and you�ve got access to your applications. The problem though is probably these vulnerabilities that means it can spread that much faster and jump over between platforms.

The last one, my favorite though, kind of something I wanted to do but what are devious little minds can think of. So whatever you can think to be, once you own that page, once you control the DOM as you saw earlier during the JQuery recession, you can do anything to the page.

You can do anything to the page. You can make it look different. You can send this somewhere else. You can collect cookie information, anything you want. All right. So what about education? How privilege is it in education? Now this is actually from 2008. It�s a security consulting company. They scanned 900 sites. Out of those 900 sites, 88% of the educational sites they scanned have high vulnerabilities.

High vulnerabilities include SQL injection, cross-site request forgery or cross-site scripting. So it�s a huge problem. Every year, before I come here, I come and go through the list of people that come and go to your school site and I start tinkering, a little bit. And at least 6 out of 10 of the sites I scanned always have this small problem. All right, so now let�s talk about why as an institute, I mean, why is the higher education specifically, why are we such a target? How come we�re so attractive to attackers? Anybody have a guess?

Yes. Decentralized is a big one. There�s usually, especially in larger schools, there�s no centralized service. It�s all decentralized across the whole place. You never have consistency. It�s very hard to get a .edu. You can�t just be anybody and sign up a .edu. Technically, you�re not supposed to be able to sign up a .edu. There have been some instances but you should be hired in institute. �Student information�there are all kinds of student information. What�s that?

Audience: Trustee.

Paul Gilzow: Trustee. Yeah, exactly, because people trust us. People trust our sites. As an example, my wife is a high school science teacher. Every year this comes up, she�ll be grading papers and the student will try to use Wikipedia as the source in their paper. She gets all upset. And I said, �OK, well, how - but you know you�ve got five or six different sessions, 30 kids in a class, you know, like 182 or 200 students and you�re grading all these papers.�

How in the world do you flesh out all these sites that they sourced to be able to know which one is legitimate or not? She said, �Well, you know, we do one or two things. �Either we give them a pre-approved list of sites they can use or if it�s a higher-ed site and the information that�s correct, I�ll let it pass.� So again, people trust our sites. All right. Now, you guys from UNL are here. So I�m going to pick on just a second. What are the things that have made this even worse in the last year of URL shortener? What does a URL shorteners do?

It�s shortens a link, right? So do you know when you click on a link, do you know where you�re going? No! All right. And one of the things that has been happening a lot recently are higher-end institutes is to treating their own URL shorteners like UNL did with go.unl. All right. Let�s say that you meet some people here at the conference in the next couple of days like myself and and maybe one of you guys. Send you a link. Now you probably aren�t going to trust any link I send you after this conference but pretend that you do.

If you got these too, which one would you trust? �UNO, what? �Because you think it�s UNO, right? �They�re another higher learning institute. They�re good. �They got their stuff together. �They know what they�re doing. �What the time when these two are generated. �They both went the same compromised site.

Now, I will give them credit after I went back to my site. I don�t know if this is such a good idea. �They fixed it. �They took care of it. �You cannot, as an anonymous person, set up links in malicious sites. �Now I�m not sure exactly what they�ve done to fix it but I�ve tried a couple more times, it blocks it.

So it has done a good job. But if your school is thinking about doing this, make sure you don�t just let anybody create a link to any site because attackers are going to jump on this. �All right, but you can say, �But wait, wait, wait, we�ve told our users, we�ve trained our users not to trust links from anybody, to be suspicious.

You�re good about this. �They know. �They�re not just supposed to click on any link that comes in their email or Twitter or where I am. �Back last year, September 2008, North Carolina State University did a little study. �They set up a group of people in a room and what they did is they had them working on a work station.

And occasionally, a little pop-up message will show up and they�d had to click on, �OK, OK� and so forth. �What they did is, some were legit and some were supposed to be malicious. They weren�t really malicious but the intention was very malicious. And the first time through the study, it was like 98% of the people did OK. That�s OK. �Well, something must be wrong, so to speak. �

So I went back and actually told them, they said, �OK, look, while you�re working, you�re going to get these pop-ups and sometimes they�re going to be legit and sometimes they�re going to be not legit and you need to pay attention. And despite that fact, 63% of them still clicked the OK button. �Just clicked OK, OK, OK, OK. �

Yeah, so again, it�s a big problem because they�re going to just click on any all although OK that pops up on them. How easy is it going for me to trick them into clicking our link especially if your institution has set up a URL shortener, and it�s about you knew. All right, so let�s get specific.

Let�s talk about what the three types of cross-site scripting are, the three main types. �First is called Non persistent or Reflective. �A reflective cross-site scripting is the most common but it relies heavily on social engineering because it�s only alive, it�s only viable, as long as the victim is on the page.

So all of you are familiar with the URL, you know, you got a question mark at the end of the page and you got a bunch of parameters after that? �In this case, in reflective cross-site scripting, the payload, the actual attack lives in the URL, lives on one of those parameters. And that�s why it relies on the social engineering. �I�ve got to trick you somehow, if you�re going to that page. �All right? �The next type is called persistent or stored. �It�s very common in Web forums, social media sites, et cetera, any place where you got users generating content or contributing back into some type of storage system.

You�re taking information. �You�re storing it. �It�s a little bit more difficult because they�re little, usually those types of things are locked down a little bit more. �But you don�t have to rely on social engineering because now, all I have to do is get the user to go to the site and because it�s stored, the server on that website replays that attack back up to everybody that comes there.

In fact, they have you, backed up. �Twitter had some problems with this recently and if you paid attention in the security world at all but, Twitter had a lot of problems with some cross-site scripting worms because they weren�t filtering out some of their stuff and would being able to spread from account to account and those were persistent types.

The last type is called local. �It�s much less likely but it�s still high dangerous. How many of you have noticed that especially in the recent past, a lot of your Help files or your desktop apps are Web-based or HTML-based as you�ve seen it the Web page. But HTML-based? Some of those HTML files are vulnerable to cross-site scripting attacks.

Now it�s difficult as an attacker to get this to run because now I�ve got to know what OS you�re on;I�ve got to know what programs you�re running; I�ve got to see if you�ve got those programs installed in your default locations. I�ve got to target down those vulnerable files. But if I can find one and I get it to run, that attack now runs with the same privileges as the log-in user.

And how many of you run Windows in here? Nobody wants to raise their hand.

[Laughter]

Paul Gilzow: �How many of you that run Windows run as an admin? Nobody is OK. All right. So that means if I get that attack to run, what does my attack run as? As an admin. There�s been some really interesting proof of concept exploits out right now. �We�re just going to a website we launched to calculate it.

It depends on browser, ah, to a degree. To a degree.

But remember, as far as the browser�s concerned, the instructions are OK, coming from that site. �I haven�t jumped in from somewhere else. �Yes, so you�re not saying, "OK big deal, a calculator launch." But I�ve launched - that attacked is launched, the program on your computer and ran it as the admin.

But it�s much harder like I�ve said because you have to know all that background information. All right, some of you, what we�ll do now is, we�ll kind of walk you some verbal examples of the three types and we�ll use some live demos. �I know that�s what most people are here for, the live demos, so I�ll go through these pretty quick.

Real quick, OPA some little acronyms in here. �OPA is the online job application system at the University of Missouri so if I refer to OPA, that�s what I�m talking about. �If I say PawPrint, that�s our single sign-on IDs. That�s what we call it. Our single sign-on IDs. All right. �So applicants have to register to this online job application system. �They say sensitive data with their account�names, addresses, possible social security number, work history, et cetera. All the information an attacker might need for identity theft. �All right? �Let�s pretend open susceptible to reflective cross-site scripting injection. �

It is not, I happen to write that one. �It has been tested thoroughly for several years now. �It doesn�t have one but we�ll pretend for the day. Now, Shawn is going to send Jane a spoofed email. �Sends her an email and says, �Hey, I found this job and you know, I know your husband. �I found this job, I know you�ve been looking for work in the university. �It�s perfect for you.� Sends to her; she clicks on it.

If she visits the URL, while she�s logged in, and happens to have cross-site request forgery vulnerability then I can, through cross-site scripting, grab that cookie ID; send it offsite to another server all together; the attacker can then take that cookie ID, put it back into his browser and take over Jane�s account, getting to all of her information.

That�s the first type. �The second type, persistent. �Let�s also pretend that OPA has a Web forum where the different applicants can go in and discuss resume techniques, jobs, et cetera. �And we�ll pretend that that forum has a persistent cross-site scripting injection vulnerability. �Shawn posts the thread to a forum, containing injection.�

Now if you want to get a whole bunch of people to go to a Web forum and read something, what do you usually do? �Let me ask it in another way, which threads in the forum are usually the most read? �You can put it that way. �What�s that?

Stupid ones, inflammatory ones, right? �Well, somebody just says something just horrible and everybody goes and to look at it, all right? �So let�s pretend that Shawn does that. �He goes in there and just said something awful. �Jane happens to view the thread, the injection runs, bypassing that same origin policy, sends her information back to Shawn and now everyone that you let that read is infected.

No need for such ordeal. �All right and the last one, a little bit harder, Jane visits compromised site, malicious JavaScript on page, launches and attacks against an HTML file that�s local-based, that happens to have a cross-site scripting injection vulnerability. It launches another attack now, running as her admin account, which she happens to run her XP machine in.

All right, so any questions on the three main types? �Any, so far? �OK. We�ll jump in the live demo. �I do have some bad news. �Bad news is, the sites that I�d normally use - there we go. �We�ve been a little slow there to catch back up. �Sites that I�d normally use for my demos have all fixed their vulnerabilities.

[Laughter]

Paul Gilzow: So that�s also good news, bad news because I was a little kind of short for a good demo. �So instead, what we�re going to do is we�re going to pick on Stanford. �Is anybody here from Stanford? �Does anybody know David Heart from Stanford? �I�ve been trying to get a hold of him for now for weeks, to talk to him about this vulnerability.

All right, if you happen to meet him here at the conference, please tell him to come visit me. �All right, so let�s go to Stanford. �There it goes. �Oh my goodness, it's huge.

All right, now on this page, unfortunately, I didn�t mean for it to be this big. Let�s find it all here.

OK. �It�s kind of hard to see I know because the projector is projecting so big. �But where on this page so far that you see right away except user�s input? �Search box. �Right, right away. �So what I�m going to do, as an attacker, I�m just going to basically walk you through the entire steps of how an attacker might do this.

As an attacker, what I�m going to do is I�m going to see how the server responds to things that I give. �All right, so what I�m going to put is some � � < abx in the end, character. �Now why am I going to use that collection of characters? �The whole bunch of stuff. �HTML? �It�s easy to find, OK.

What do you use to enclose an attribute in an HTML tag? �Either double quotes or single quote, right? �All right, how do you start an HTML tag? �Bracket there. �How do you end an HTML tag? �Bracket, abx is just there for me to help find it. �So I�ve got a whole bunch of source codes just help me find a little bit easy.

All right, so what we�re going to do now is we want to see how the server responds. �All right, it came back. �Let�s take a look at the source here. �Is that font big enough for everybody to see? �All right, let�s see what we�ve got. �So we got abx. �So what do they do? �They left the quote. �They left the single quote. �They escaped the �less than� symbol, encoded in the HTML and phished.

They left the abx and then encoded this in the end. �Now that�s no good. �I can�t do anything to that. �

In this case, down here, they encoded the double quote, left the single quote, left the less than, left the abx then encoded the data in. I still can�t do anything like that.

Let�s see, that time, the URL encoded it. �I can�t do anything with that. �That same thing again, another URL encoding, URL encoding, stripped out some stuff, stripped out some stuff, stripped out � there�s nothing in here. �OK, so no good this time. �What�s this? �What else do we have in here then? �What else might be accepting some input when you�re looking at this?

We searched for Stanford Web. �Let�s search for people. �Let�s see what happens there. �Right here, let�s try it again.

Hmm... Let's see the source. Looks like they, oops, let's go back to that. Looks like they stripped it out or they, well, encoded. They encoded it there. �Stripped it out, stripped it out. �They�ve stripped out everything. Hmmm...Can�t do anything with that.

Audience: Who else accept input here?

Paul Gilzow: Maybe, you�re URL�s kind of small. �Oh, who said that? �Ah, yeah, what? Look right here. �Search within, what is this? �Who drop down the list, right?�That�s user input. How many of you have used Firefox? �Good! �How many of you used the Web developer�s toolbar in Firefox? �Oh, even better. All right.

So you guys are familiar with a Web developer�s toolbar. �All right, so in the forum option, one of the things that we can do is convert select elements to text inputs. �So I can change that drop down list, what they�ve got here as everyone, university, university, faculty, staff, et cetera. �I can change that over to a text area.

Ah yes, so I can change everyone. �We�ll do the same little stray. �I�ll go back up here and change this abx to Smith, and now let�s see what happens. �What happened? �Just right off the back, do you see something wrong? Something�s not right with that. �That�s not what I should be seeing, right?

So let�s take a look. �Let�s see some of the source on this. It looks fine in here. Yes. See why I wanted to be able to find this thing faster. �It�s kind of hard. �So what�s happened?

What was that?

Paul Gilzow: Ah, yeah, another one now we got. �We got quote that�s now ending the href essentially, and then we got a closing bracket, which is, as far as the browser�s concerned, it�s telling it that anchor now is done. �So do you remember buffer overflows in a couple of years ago? �This isn�t a buffer overflow.

It�s kind of the same thing. �We�re trying to, as an attacker, we�re trying to break out of what we�re supposed to be placed into so that we can get stuff into the page and take over that DOM. All right, so let�s try something. Let�s go back in here. �Do the same thing, change that to... �All right, so what I did is I�ve got.�Got an in quote. Remember I left in that quote, in the attribute. �

I�m going to tell it in the anchor and then I�m going to insert my own script tag. �Let�s see what happens. So what does that mean?

[Laughter]

Paul Gilzow: I mean there�s probably got a problem there. �All right, now you might be thinking. OK well, let�s look in the URL. �We got a script to fire but � so what method is the Form using? �POST. �Now you can still launch an attack if the Form is using POSTS.

It�s not easy. �It�s still possible but it�s definitely not as easy as using the GET, the GET method, right? �So what we want is an attacker to be able to GET method. �It just so happens that in the Form, on the toolbar thing, we can divert Form methods from POST to GET.

And we�ll put our little string back in here and see if it let�s us do it. Every time it displays it, I may have done this many times though. �Oh, really? �I should have picked a dinner person. �Oh my gosh!

[Laughter]

Paul Gilzow: Oops! �Oh, man! �All right, I thought it�s done. �Ah, I should have searched on either name, jeez. �All right, yeah, let�s see. �Let�s just � we�ll go over to � hold on. �Yes I can. �Yes, I can. �We�ll do all those part.

Kill that one for a second. Go to Safari real quick. �All right, but you might be saying all right, that�s fine. �But what�s on alert view? �That�s no big deal, right? �It�s no big deal.

Let�s say, instead, that I change it to, not just say alert, but to do a script source. �Now what�s it going to do? �It�s going to load in, what? Whatever that URL points to, that URL happens to point to one of my sites that contains a JavaScript file. �I happen to have the whole URL copied here, already set up and notice I didn�t just put HTTP sourcing. I encoded it so if the user saw it, he�ll little quite know what it is.

Even trickier, this happens to point to this. �So instead, I could just copy this one. Let�s load the page, still loading. Oh-oh!

[Music]

OK, now where are we at? �We�re still at Stanford, aren�t we? �Does that look like Stanford anymore? �No, we�ve completely taken over the DOM. �We�ve got rid of the background. �We�ve got rid of the entire contents of the body and we embedded a YouTube video. �All right, so if I can do that, what can I do?

I can do anything I want, can�t I? �All right, this is the danger of cross-site scripting. �Simply from injecting into a URL, a payload, I can take over somebody�s entire site. �From there, I can launch cross-site request forgery and if you�re not familiar with that, basically, you take the cookie value and then when you log-in into a site, the site assigned you a cookie.

And that�s how I know that you go from page to page to page, who you are. �Cross-site request forgery vulnerability is where the application doesn�t do enough checks on that cookie value to make sure that the person who�s saying they have this value is really that person.

So I can steal that cookie value, put it into my browser and assume that person�s role, for their account. �This is the danger. �Now real quick, we�re going to do, we�re going to look at a persistent vulnerability. �We�ll go over here and build Windows real quick because that�s where my editor runs in, maybe, if he cooperates here. Here it goes.

Paul Gilzow: Our editor? �How can you make new PHP? You should check out Mewsker's PHP. It�s awesome, awesome application for development. It�s very similar to Microsoft�s .Net Editor and Visual Studio Editor. It does code completions, etc. All right. So, sorry I can�t really see some of the words and stuff. Or is this from now?

Basically, this is going to be� Yes, absolutely, absolutely! So we�re going to run this website. This is just a real rough, kind of like a Twitter-type thing. It�s just going to take user comments, store them, and then plan back to the users they can visit. To fire up here. So you�re getting your computers some profit and some.

Come on, hurry up. You just have to stop. Hope it�s still loading. Maybe it�s to turn and run those once over into Firefox as part of what it is so the alerts gone, song in the hits. Oh, there it goes. �It�s fine. OK. Good. So again, just a real basic some steps of user input. Then print those comments back out.

So again, just like last time, insert some comments here. All right. New comment. You can see the �View Source� here. See what I did. Do anything to it. Absolutely not. I didn�t do a thing to it. Just spit it back up verbatim. Probably the worst thing you can possibly do.

So now, let�s put another comment. Oh! �I did not want to go into that. Here we go. All right. Instead what I�m trying to do we�ll do script. So let me do this time. Put that script, get it right back into the page, and you�re in.

The problem here is now, it is stored permanently. That means any user that comes here, hopefully IE doesn't take as long to load. But any user that comes to this site now is going to have that attack replay back to them.

So now if I go into IE and I�m going to that same website. Ponk! It�s going to play every single time. This is how the Twitter worm spread. We got stored into user�s profiles, and so then when you enter them their profile and it went into your profile. And this keeps spreading in the storage system cross-site script vulnerability.

Alright. So any questions so far? Anything? Yup. It�s exact same problem. You can�t trust anything. In fact when I got here, oops, probably when we get out. There we go. What can we do to protect our sites?
Yeah, exactly. Paranoid, put on your tinfoil hats. The best thing you can do is be paranoid. Be very paranoid. Now I�m paranoid by nature.

For example, I brought three white shirts of the exact same store. So I spilled coffee on one before my presentation. �I have two back ups. That�s how paranoid I am.

So you can not trust anybody as a developer. You can�t trust any input at all. You have to assume that every piece of data no matter where it�s coming from, it doesn�t matter. �If it�s coming from the database or an external, it is a potential attack. You have to check everything. Again, there�s not again but another thing is layers or a defense in depth military strategy.

What you do is instead of just having one defense, you have a whole bunch of defenses. So an attacker has to continuously fight to try to get them one, up to one, to the next one, to the next one, because most attackers are pretty lazy. What they�re looking for is the low-hanging fruit. They�re looking for the sites that have vulnerabilities that are wide open, that they don�t really have to do a whole lot of work for.

Now that�s not to say they won�t still attack you because as educationalist in philosophy pointed out, �We have additional problems like student information, and that information is valuable.�

Brand new credit histories can be taken. So anybody can finally get through but what you want to do is make it as hard as possible to get through. So some things that we can do to protect our apps--input filtering. Input filtering is also referred to as black-listing. So one of the sites earlier we saw was striping stuff out. You know they put that double quote in, they took it away. That�s blacklisting.

But what�s the problem with blacklisting? You�ve got to think of everything. You�ve got to think of every possible thing that somebody could use. As an example, we go back with the American Red Cross. Just found this one as we�re sitting in there with the American Red Cross. �Yes, American Red Cross. Safari again.�Excellent. OK.

We have a little search box. So we�re sitting in the presentation of American Red Cross and I went to check it out with the exact same thing. I said �All right, adx.� It's loading. Ah! What happened there? Let�s spit it out well. It may not spit out everything. But at least I know that double quote, the ending quote or anything that double quotes, I was able to pop up, wasn�t I? All right now, let�s try a little bit more sophisticated. Let�s try a stress-like a script alert and see what they did.

And what�s up? �And no doubt, you�re very welcome. Oh-oh! Let�s skip this data. Let�s go right back in. Al right. So it�s too hard to try to catch everything. In the American Red Cross, I found the vulnerability. Basically, they stripped out script tags. They stripped out parentheses. They stripped out quotes. But I was still able to find one who�s using some other JavaScript tricks. If we get time, I�ll try to show you at the end. But you can�t keep up with it. You just cant� keep up with the blacklist.

It�s OK. It�s certainly not something you shouldn�t do. You should do filter. You should look for those things and take them out if you have to, if you can. But you can�t rely on it as your only defense. The second one is input validation. Back when we saw Stanford and change the drop-down list, the text we�re able to inject there.

What could they have done to block that attack? So which I didn�t put validation, only except those who helped who don�t have validation. �That was the list, wasn�t it? So what should they accept? Only things on the list, right? Most likely that list came from an array so all they have to do is go back and say, �All right, for this input, if it�s not in IRA, spit it out.� That�s validation. Only accept things that you�re expecting to accept.
Output in coding. You saw that happen. You should output the code everything possible. If you encode, the greater they assemble, though I can�t bust out of. I have to have that intag there in.

Nothing you can do is called the Web Firewall on Intrusion Detection System. �This is another layer that sits on top of your app. What it does is, it scans inputs as they come through that scores them. That doesn�t block them. It just scores them.

It looks at the post. It looks to get contents, and it says, �All right, for each of these in here, here is a score on a possible attack. Then it�s up to the developer to decide what to do with that score. So you can say, �All right, it scores more than a 15. They dumped it out. That�s probably an attack.

OK, it�s just another layer. You can also tidy your output. All right, as any way of messed with HTML title before. We�re looking at a couple it. What it does is it takes HTML and then tries to conform it to some standard. So if you give it an open paragraph tag and an end div tag, once it�s going to try to convert that div into paragraphs so it matches up.

All right, so you�re doing that if you�re tidying the output, well, then I can�t try to break out and the quotes that are in the end. �You�re just going to try to clean all that up and not leaving anything from standard. She was anti-Samy which happens to be part of the OWASP which is the Online Web Application Security Project. Remember all that. It is a library to do exactly encoding to try and - it was built shortly after the Samy worm of getting around cross-site scripting vulnerabilities..

All right. Sorry about the demos being slow. Do you have any questions? Yes? �That�s specifically the same but almost every language now has some type of security or anti-cross-site scripting vulnerability library that you can use. If you go to the OWASP site, owasp.org, specifically, they have an anti-cross-site scripting library for .net, Java, PHP, pretty much all major labels which you end up.

Paul Gilzow: ...which will help. In general, it�s another layer. �You can�t rely on a 100%. .NET does the same thing; they�ve got one. �Unfortunately, there were � the .NET was going about but in .NET, you would block all your image, all your tags, anything you chart in that way just to give you air page except for into HTML.

So what you could do is you could put it into HTML and then an on-load and then fire it off. �So, it helps. I�m not saying there�s one. There is a vulnerability for that one. �I don�t know it�s on top of my head. It certainly helps, it is definitely something you should use as a defense in-depth strategy. �I wouldn�t rely on it a 100% if you don�t know if it�s going to take care of everything.

I kind of mentioned that, if you were paying attention to a JQuery session, the Twitter feed during the JQuery session, we talked about validation plug in, same things. �Frameworks, great framework, don�t get me wrong but you can�t rely on point side validation at all as far as for security.

You can as a nice user feature but not the same thing for service site frameworks. You can�t rely on a 100% because you didn�t write it. You don�t know what is isn�t in it.. They might have gotten it all; they might not. �Plus a lot of those frameworks are open-sourced which means the attacker or an attacker can go in and read through those as well and look for both codes, possible vulnerability attackers.

Get defense in depth that, that if you take anything away from here, defense in depth, you�re going to use a whole bunch of different strategies built on top of each other.

One other thing I would like to mention and I have this question the last time I presented this is, �What as a user can I do?� In other words, I�m not a developer. I don�t do anything, maybe I�m a PR person. And just as a user, what can you do? �Unfortunately, not a lot right now. �The newer browsers are doing a better job; IE8 has built-in cross-site scripting vulnerability features. It�s blocked against it.

The newer versions of Firefox do it. �The new versions of Chrome do it. And they�re good to a point but they�re still not a 100%. �So as a user, you can certainly upgrade to the latest versions but you still got to be careful where you go. �You can use no script even those script has some -I happen to know a guy that writes no script.

And there�s still a few � he�s excellent. �He�s very good. �He usually takes care of it immediately. Problem no script though sometimes is that it can disable the functionality of a website. �

It�s annoying sometimes, which is why most users don�t use it. �I mean a lot- people that are security-conscious do. But the general average users, it's just too annoying for them�Any other questions or comments? �Anyone? �Are we on time or do we got a few more minutes? �Oh one minute, may I can finish this up. �Oh, it timed out. �OK, the gateway timed out. �Did I maybe -? My connection, OK. Ha! Let�s go in here. �Oh, it didn�t do anything. �Let�s do this stay on.. Now, it�s over. I�ll just do the one that works on this one. �OK, so we�ll say, �A setter equals alert� �Did we do it? Yes.

And if I have a back over. I need some luck. Yes I do, hold on. Yes, I do need a quote. Thank you. That�s what I mean. Oh my God! This works at Firefox.

[Laughter]

Wah! Can I even get to the new window? �I can�t even get to the new window. �Ah! �All right. Well, if that will work, I�ll try to get through the rest of this. �If you want to see it, I�ll show it to you. �Basically, A setters says, �Create A as an object; take it setter method, make it an a list of the alert then set A, the object, to one which passes the one back to its setter function, which is the alert, and you get alert.�

I know it�s kind of complicated, but again, no parenthesis. �All I had to do is have a quote and then use our mouse over and as soon as your mouse over, bum. �You can have a new location, you can have a set of A list to any of the built in JavaScript functions. �

So get a backed up blacklisting that�s why you can�t rely on blacklisting or you can open an iFRAME. Sorry. Sorry I messed up on using Smith there. �So I�ll be here for the next hour.

[Laughter]

Paul Gilzow: What�s the Force Quit on an Apple? �What is it? �Command, option, escape. Firefox force quit, goodbye! Thank you. Ah! Wooh!

[Applause]