Cross-site Scripting – An Introduction

You won’t find me delving into the world of web design too often. Once in a blue moon, maybe I’ll fool around with some JavaScript or XHTML but when I do, I just don’t find it to be that fun. That awful mash-up of control statements, formatting, and actual data leaves me with a strange combination of boredom and headache. That’s a whole other post though so I won’t digress. However, since I’m obviously writing this blog, I’ve had to bite the bullet for the past couple of days and refresh my memory of web applications. For some reason, I keep finding myself coming back to the subject of cross-site scripting. There’s just something about the idea of code “injection” that really gets me excited. Besides, according to CWE, cross-site scripting has become the most commonly reported security vulnerability next to buffer overflows; what’s not awesome about that!?

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.

In its most basic form, cross-site scripting (XSS) is a form of code injection that allows an attacker to embed or “inject” malicious code into an otherwise legitimate website. Essentially, the attacker is taking advantage of the fact that the web application thinks it’s ok to store code from an unknown source because it doesn’t know any better. This code generally takes the form of client-side scripts in JavaScript but just about any embedded content poses a potential threat such as VBScript, PHP, ASP, Flash, ActiveX, etc. That’s part of what makes XSS so widespread; it’s not associated with just one or two languages. It’s not like you could use VBScript for your web app because it’s “safer than JavaScript.” XSS exists due to poor design practices on part of the web developer.

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.

Consider the following scenario. Imagine that you’ve just suffered a horribly traumatic brain aneurysm which has left your brain so impaired that you now actually enjoy visiting sites like Facebook and Twitter. <tap on the shoulder followed by whispering> Wait…what? Regular non-disabled people habitually update their Facebook status at a rate that nearly suggests narcissistic personality disorder too? I always thought those people were just mentally impaired. Hmm, guess you learn something dumb everyday. Anyway, imagine that you are a completely normal person logged into your Facebook. You receive an email informing you that Facebook has been super l33t h4ck3d and you need to re-login and change your password…fast! You, being a not mentally impaired person who believes that kind of thing, clicks on the link provided in the email. The link really does direct you to Facebook but contains some malicious JavaScript embedded in it. You login again, all fine and dandy, while your browser blindly executes the embedded script that steals your session cookie and sends it to Now evil bad guys can hijack your session by impersonating you. I’ll leave the rest up to your imagination. Actually, Facebook has fallen victim to several XSS attacks in the past.

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.

Ever wondered why every message board you visit doesn’t allow you to embed HTML tags in your posts? Here’s why. Imagine an attacker – let’s call him Stu, Stu Pid – discovers that the Foobar message boards allow users to embed HTML tags in posts. Stu Pid starts a new thread with some malicious JavaScript embedded in it. He lays down some flamebait by giving it a highly controversial topic to ensure that plenty of people visit it to start a massive flame war. Maybe he calls it “Why GNU/Linux is Better Than Windows.” For each person that merely visits the page, Stu’s malicious code gets run within their browser, stealing their session cookie, and relaying it to his site. Stu Pid now owns the accounts of every person who viewed his thread. Given the subject matter, that’s probably a lot.

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.

Comments are closed.