What are XSS Attacks?
XSS attacks are attacks that target the end user instead of your actual site. Vulnerable web applications that don't check or sanitize incoming data let arbitrary code to run on a client computer (such as Javascript). The end result can be anything from stealing cookie data or redirecting to a different site, to embedding a browser exploit on a page. Anything that can be done with Javascript (a lot!) can be done if your application is vulnerable.

An Example
As always, it's easier to understand concepts when given an example -- so let's make one.

Bob, a website owner, has created a custom gallery script. He created a feature that let his viewers comment on his photos by submitting a form. To enhance their messages, he lets them use certain codes to format their text (ie. bbcode, like the codes we use here on WT). For the sake of simplicity, let's say he only let users use a [img] code.

In his code, he converts the img code to HTML with this bit of regex:

PHP Code:

$message = preg_replace('#\[img\](.*?)\[/img\]#', '<img src="$1" />', $message); 


So if a user enters:

My cat: [img]www.mysite.com/cat.jpg[/img]

Bob's script will output:

My cat: <img src="www.mysite.com/cat.jpg" />

Can you spot the problem? He does not check what the user inputs between the img codes, and he is blindly trusting the user to enter correctly formatted data.

One day, an evil site owner named Jack comes along. Jack is jealous of all of Bob's traffic and decides he wants to steal some of it. He recognizes the error Bob made in his script, and exploits it. In 20 minutes, Jack has replied to many of Bob's recent gallery entries with the following comment:

Hi bob, very nice pic! [img]http://www.google.com/images/logo.gif" onload="window.location='http://jacks-site.com/'[/img]

And, of course, Bob's comment script obediantly turns it into HTML (red is Jack's input):

Hi bob, very nice pic! <img src="http://google.com/images/logo.gif" onload="window.location='http://jacks-site.com/'" />

And every time a user views one of Bob's most recent gallery photos, they are rudely redirected to Jack's site.

What Happened?
Since Bob's script didn't check Jack's input, he allowed Jack to insert his own HTML. By inserting a quote after the URL to his image (in this case, the Google logo) he closed the quote for the src attribute. Then he just entered some code that would redirect the user to his website once the image was loaded.

How do I Prevent XSS Attacks?
To prevent XSS attacks, you just have to check and sanitize all user inputted data that you plan on using.

For starters, disallow all HTML. Use htmlspecialchars() to convert HTML characters into HTML entities. So characters like < and > that mark the beginning/end of a tag are turned into < and >. It is not enough to simply use strip_tags() to only allow some tags as the function does not strip out harmful attributes like the onclick or onload. Even an innocent looking <strong> tag can contain some nasty code.

If you need to allow users to enter formatted text, then you have to create some sort of code like BBCode. But make sure you check and sanitize the output or else you'll suffer from vulnerabilities like Bob. For example, if you have a [url] tag that enters a link, make sure users don't enter something like

javascript:alert("Hello");

Make sure they enter valid URL's.

The rule of thumb: If it will ever be outputted, then check and sanitize it.

Thanks for the tip.

You said, "Use htmlspecialchars() to convert HTML characters into HTML entities."

Isn't that the job of htmlentities and, if not, what is the difference between the two

htmlspecialchars() will only convert certain characters to HTML entities, like <, > and quotes (they're listed on the php help page listed). htmlentities() converts ALL characters that have an entity are converted.

Originally Posted by htmlentities() manual page

This function is identical to htmlspecialchars() in all ways, except with htmlentities(), all characters which have HTML character entity equivalents are translated into these entities.

Thanks.

Sound advice,

Ibbo

One more point to add.

- Never ever trust the user input.

The rule of thumb: If it will ever be outputted, then check and sanitize it.

Can it be like...
If it will ever be used at any point, then check and sanitize it.

"used" in the sense, either it can be an "input" for database or "output" for a page.

If you expect a number as input, junk the data if the input is not a number.

If you expect a text as input, clean the data for all red flag characters such as special characters < > $ . ( For Unicode characters... can somebody point me in the right direction. I am not aware how to clean them. )

Some important areas to look for in a page to prevent XSS attack.
1. Query Strings
2. Forms (GET or POST)
Input texts and Text areas in the page.
3. Image tags
4. Anchors

Some important areas to look for in a page to prevent XSS attack.
1. Query Strings
2. Forms (GET or POST)
Input texts and Text areas in the page.
3. Image tags
4. Anchors

vivekar I don't follow... your saying to check image and anchor tags I put in my files - for what?

If I validate the input to my contact form (and I do) and someone slips in some code instead of their first name - it is just going to be saved in a text file and emailed as a text file attachment. Am I missing something? What is it you want us looking for exactly in the things you list?

I can see point Chroder made, his good example illustrated it well, but I'm not making it past your warning.... can you maybe give us some examples of the danger?

Thanks

Good article, you learn something new every day! This will definatly come in handy in a few of my projects.

@CurrentWave

Sorry for the very delayed reply. I have unchecked the subscribe option for the threads. I just checked it now.

what I meant was to clean up the IMG and A tags and their attributes in a TEXTAREA.

Please check out http://kuza55.blogspot.com/2006/03/w...-xss-worm.html

A remote attacker could post a malicious message containing JavaScript embedded within [IMG] tags, which would be executed in the victim's Web browser once the message is viewed.
An attacker could also exploit cross-site scripting vulnerabilities by creating a malicious URL link containing embedded script, which would be executed in the victim's Web browser in the security context of the hosting site, once the link is clicked.

http://xforce.iss.net/xforce/xfdb/8278

An old thread, but a sticky, so let me add a note here: When sanitizing information, retain only what you want. Many people try to remove what they don't want, but that set of things is far greater.

For example, let's say that you have the image code above. Then what you do want is letters, numbers, periods, forward slashes, underscores, dashes, and colons. Everything else, you don't want.

I frequently use preg_replace for this as shown here:

PHP Code:

$good_file_name = preg_replace('/[^a-z\-_0-9\.:\/]/i','',$original_input_file_name); 


The above technique can be expanded to assert more conditions that you want (such as the file existing, starting with http://, etc.), but the key thing is to stick with ensuring data contains only what's allowed and remove everything else.

great post, thanks!