The X in XSS

Illustration of thief with bag over his shoulder and the word XSS

I’ve mentioned Cross-Site Scripting, aka XSS, in some of my previous posts. And I’m sure you’ve heard of it as well.

XSS is often categorised as either reflected XSS or stored XSS. And then DOM-based XSS was added. OWASP now categorises XSS as:

  • Client XSS
  • Server XSS

Both of these can be either reflected or stored, which can make it all a little confusing.

What is XSS?

XSS is a form of code injection. An attacker injects malicious client-side code into the message sent between the server and the client.

The malicious code is usually JavaScript, although it can be HTML, Flash or anything else that the browser can execute.

The user’s browser (client) thinks the script came from the server, and does not know that it should not be trusted. So it executes the script, with potentially devastating consequences.

Server XSS

Server XSS means the malicious code comes from the server. Yes, that’s your trusted server! How?

The user entered data on a form and submitted it. Along the way malicious code was added to the form data. You didn’t sanitise the data that the user sent. And then you sent that unsanitised data right back to the user! (You might remember that I previously wrote about cleaning input data.)

If you sent the data back to the user without storing it, it is reflected XSS.

If you stored the unsanitised data, then it could potentially be sent to many users. This is stored XSS. An example is malicious code injected in a comment on a blog post.

Client XSS

In this case, the malicious code is not on the server. Untrusted data is used to update the DOM on the page with an unsafe JavaScript call.

What can XSS do?

We know that JavaScript on the client runs in a controlled environment. It has limited access to things like the user’s operating system. But despite that, XSS can have serious consequences. Here are a few examples:

  • The malicious script can access cookies, session tokens, or other sensitive information kept by the browser and used with that site. So it could impersonate the user.
  • XSS can rewrite the content of the HTML page. It might, for example, redirect form input to a different URL.
  • XSS can create keyloggers. A keylogger stores all your keystrokes and send them to a server controlled by a hacker.
  • XSS is also used with other types of attacks, such as Cross-Site Request Forgery (CSRF). We’ll talk about CSRF in a later email.

XSS is a very real problem. That’s why it is #7 on the OWASP top 10 list. Next week we’ll look at some of the ways to protect against XSS.

If you haven’t already, join our Security Spotlight series. You’ll get a weekly email about web application security.

Leave a Comment

Your email address will not be published. Required fields are marked *