XSS Part 1 - What it is

In this first of four post about XSS, we'll define what it is. The following posts will talk about how the attack is executed, how you can stop it and what resources are available for you. By the end, you will not have any excuses that make any sense as to why security isn't part of what you do.

First, let's define XSS. XSS stands for "Cross-Site Scripting" which means a script on one site is executing at another site, in your browser. OWASP (Open Web Application Security Project)¹ has listed XSS as the #2 web attack risk for 2010².

From their document outlining the top risks for 2010, they define XSS as:
"XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites."

Ouch! Sounds nasty, and it is.

So what does this mean to you as a developer? You have a big problem if you take untrusted data and send it to a browser without validation/escaping. So let's define this a little closer.

"Untrusted Data"

-- how do you know what data to trust? Are you trusting your database since it is behind the firewall and is only accessible by system admins? You are? Really?? How does your data get into the database? What if your admins are corrupt and decide to modify the data by hand? Don't ever trust database input. You don't know how it got there. Don't trust user supplied input from form fields. Don't trust URL querystrings. Don't trust anything outside of your app.

Paranoid mentality? Perhaps...but will your CEO care if you say "We felt we were being too paranoid so we trusted that data and didn't realize it would bite us." You can't be too paranoid. Get over the stigma and protect your data.

"Validation/escaping"

-- this simply means you have tested that the data is what you expect to receive, and that you are outputing what you expect to output to the screen by revalidating it and making sure special characters are escaped to render them harmless. Escaping means taking a ">" symbol and making it into ">" for example. If you expect a date for input, make sure it is a date and not some script that will run in the browser. Think people won't use your app like that? Wrong. We're talking about cash here. People will do all sorts of things for some green. If they find your app easy prey, they will use it and tell their friends what the hole is.

Why is this an issue?

-- well, let's assume you leave a field on your web form that accepts 100 characters and you don't validate it. If the user puts a script tag in there instead and it calls a script from a bad site, that runs on your machine and takes your cookies and sends them to Russia, let's say...you won't be happy if the cookie is to your online banking site and someone just used it to transfer money to themselves in your name.

"So if I don't trust any user input and I validate all input/output plus escape output, am I safe from XSS?" Great question. See Part 3 of this series to know for sure. But first, to help you answer the question yourself, let's take a look at how an XSS exploit happens. That is coming up in the next post.

¹ http://www.owasp.org
² http://www.owasp.org/images/0/0f/OWASP_T10_-_2010_rc1.pdf