I’m going to make this into a three-part series of posts. Today will be a general overview of what cross-site scripting is and the different types of attacks. Next I’ll include some real world examples and common attack vectors. Things just wouldn’t be complete if I didn’t talk about how to prevent these naughty scripts and how to review your code for XSS vulnerabilities which will be the focus of the last post.
XSS attacks can occur anywhere a web application that makes use of input from the user but fails to sanitize it properly. Unvalidated user input is really just the first criteria for an attack. The real damage happens when that input is used by the server to generate dynamic content such as a results page.
So what can attackers do with all this? The consequences range from being a mere annoyance to total account take overs. In severe cases, an attacker can steal your session cookie, hijack your session, and completely take over your account. Even more dangerous, XSS vulnerabilities can lead to the installation of trojans, full disclosure of sensitive user information, redirection to other malicious sites, and on and on; the number of possibilities is really up to the attacker’s imagination. Think about what could happen if a pharmaceutical site was vulnerable to an XSS flaw. An attacker could modify dosage information for patients which could lead to an overdose. Imagine that: literally killing people with code. That’s some serious shit. It’d take a pretty heartless person to accomplish something like that but my point is that anything is possible with XSS.
A classic example is the user login form. When a user enters their username at a login page, the string is typically redisplayed unchanged after singing in to indicate that they have successfully logged in. If the username field is not properly sanitized by rejecting or at least encoding HTML control characters, it becomes a gaping hole for attackers to do as they please. This is actually a certain type of XSS called a reflected attack. Let’s take a look at what that means.
The types of attacks that use cross-site scripting as an attack vector are nearly limitless but security experts generally recognize two different types of attacks: non-persistent (or reflected) attacks and persistent (or stored) attacks. As a matter of fact, there’s actually a third type called a DOM-based attack where the DOM environment is actually modified. However, this is a more advanced form of XSS and I’m not really interested in going that deep into the subject. For those of you who are curious, OWASP has a great article about it here.
Non-persistent XSS vulnerabilities are among the most common types that show up and is generally what is referred to when people talk about cross-site scripting. They occur when input data supplied by a web form is included in the dynamic content of the server’s response. They are sometimes called reflected attacks because the injected code is said to be “reflected” off the web server. You might be thinking “What’s so dangerous about all this if all you can do is infect your own page? No big deal. Whatever, I’m just gonna go watch videos of dancing pigs now.” Well, you’re kind of right. However, sprinkle on a small layer of social engineering and now you’re getting somewhere. Reflected XSS attacks are usually delivered in emails where the victim is baited into visiting a seemingly innocent website. The included URL is specially crafted to point to a legitimate website but also contains the XSS vector.
The second type of XSS vulnerability is the persistent attack. This occurs when the data input by the attacker is not just included in the dynamic content but is actually stored on the web server permanently. That’s why it’s also called a stored attack. As you’d imagine, this is what makes it the most devastating of XSS flaws. This malicious code typically gets stored in places like databases, message boards, guestbooks, and blog comments. Since the code is stored on the server, it will permanently be displayed on normal pages to anybody that visits it; there’s no need to trick users into visiting a specially crafted URL.
That’s the basics of cross-site scripting. Next week I’ll be setting up a simple web server with a LAMP stack on my home network and try to find all the different ways I can break it. Fun! In my next post, I’ll show you some of the things I was able to do with a couple of examples and common attack vectors.