Security 101: Cross-Site Scripting

In cyber security, attention is concentrated on the new -- zero-day exploits, for example, are big news and big business. But old threats can still cause big problems for organizations, even when the threats are almost old enough to legally have a drink to celebrate their victories.

Cross-site scripting, or XSS, was first described by Microsoft engineers on January 16, 2000. By 2007, it was considered the most common exploit for web-based applications. And in 2020 it is still one of the most common, and dangerous, exploit technique. So what, exactly, is XSS, and why is it still something we worry about today?

XSS Basics

When a user types in a URL, they expect their browser to request data from a server, which will then be sent back to the browser and rendered on the user's screen. In the late 1990s, hackers found that they could use Javascript to cause one web site to be loaded into a frame in a second web site with no visual notification. The first (illicit) web site coold then capture data from a look-alike legitimate form, steal credentials, launch attacks, and do all sorts of other things. Because the attack used a pair of web sites and was launched with a script, the technique became known as cross-site scripting.

Modern web sites have become increasingly complex, and the process for making a web page (or application) appear in a browser has become more complicated. If every piece of code served up to a user has been carefully vetted and approved by the server's owner, that complex process can be secure and trustworthy, but there are several ways in which a hacker can bend the process to their advantage.

Trouble in the DOM

Before going any further, there's a term to be introduced: DOM. In this context, DOM is the acronym for Document Object Model, and it's a brief way to talk about the entirety of web application or site that's rendered within a user's browser. The DOM is important because it includes all the scripts, objects, and references that are used to build the web page that appears in a user's browser. It's also part of the name of a type of XSS.

All XSS types depend on an attackers ability to change legitimate code, on the server, on the user's computer, or in transit between the two. With that in mind, let's look at the three types of XSS.

Type 1 -- This type, also known as persistent or stored XSS, is possible when the user stores data on a server and then is able to retrieve that data with little interference. Think of blog community comments, message forums, and the like. If the information returned to the user isn't vetted for security reasons, an attacker can inject scripts into the fields and have them execute with no notice to the user. This type of XSS typically involves illicit changes to the source code for the web page and requires access to the web server.

Type 2 -- Non-persistent, or reflected, XSS is possible when user input is immediately reflected back to the user with no validation and no storage on the server. This type of XSS attack can take place entirely within the browser, never involving the legitimate server until time to offer up data for the taking. Everything involved in the attack can happen on the client, with the results being illicit data requested from the server.

Type 0 -- This was the last type of XSS defined and it is also called a DOM-based XSS. This is a type of attack that, like the Type 2, may be launched entirely within the browser, but in this case the malicious payload may not request data -- it can be a script that causes action on a third-party server. This type of attack often depends on mal-formed URLs for its operation, sometimes requesting that a malicious script be launched on a server that the user doesn't know and never sees.

Just to make things more complicated, these three types of attack can be mixed and matched within a single campaign, with different XSS types used in different stages of a complex campaign. The key to all of them is that  a third-party must change code on the server, or within the browser environment, without permission.

Saying No to XSS

So what's a developer (or security team) to do about XSS? The most important, most basic, rule is this: Never allow data to be inserted or changed where there isn't a good reason for it. That sounds simple, but there are a number of different rules to be followed to make it work.

One of the first rules is to make sure that any of the characters that can kick off a scripting session (things like &, <, >, ", ', and /) are designated by, and required to be, their hexadecimal entities rather than the ASCII characters you see here.

Next, make sure that all parameters and script calls are escaped -- put inside quotation marks. The specifications will allow for variables and labels without the quotation marks, but doing so leaves the door open to XSS hackers.

Finally, regularly inspect the code on your web site for illicit or unapproved changes. Solit version control and code monitoring will go a long way toward stamping out XSS on your site.

The basic reason XSS still exists is that developers are still under time pressure and hackers still know this. Take the time to opt for secure code, and you'll force attackers to use newer, more expensive, tools to reach your data.

Related content: