March 13, 2017 By Paul Ionescu 5 min read

In the previous three chapters of this series, we discussed ways for developers to put their hacker hats on and program defensively to prevent security bugs from cropping up in their software. We described the nature of SQL injection, OS command injection and buffer overflow attacks. We did not, however, touch upon the No. 1 issue that plagues web application developers: cross-site scripting (XSS).

Indeed, XSS ranks quite high in the CWE/SANS Top 25 Most Dangerous Software Errors list:

Rank Name
1 Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)
2 Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)
3 Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
4 Improper Neutralization of Input During Web Page Generation (‘Cross-site Scripting’)
Scroll to view full table

XSS is easy to test for. In fact, it is probably one of the most common vulnerability types found in software. However, XSS can be really hard to fix. When maintaining a large web application that was written 10 years ago using servlet technology, there may be thousands of places where XSS lays dormant. Newer technologies using rich, client-side user interfaces (UIs) are not spared, either.

To top it all off, most developers are using web technologies nowadays, even in mobile apps, so XSS is a big headache for everyone.

Notorious Examples of Cross-Site Scripting

XSS made history with the Samy worm, the fastest spreading virus of all time. The worm was a relatively harmless and very original type of virus that self-replicated by altering the profile pages of MySpace users and sending friend requests to its creator, now-famous hacker Samy Kamkar, who ended up in hot water with authorities after the incident. Twitter was also targeted by a similar XSS worm that embedded malicious links on the website StalkDaily.

Besides infections on social networking sites, XSS has been used for financial gain, most notably in attacks against e-commerce giant eBay. Cybercriminals injected malicious scripts into several listings for cheap iPhones. The scripts sent users to a spoofed login page that harvested their credentials.

What Is the Programming Flaw?

XSS occurs when a webpage renders user input as HTML or JavaScript code. Below are some examples of code that renders the user input.

Figure 1 shows several locations within the HTML markup of a server-generated page:

Figure 2 shows input rendered as is within the JavaScript code of a server-generated page:

Figure 3 shows XSS being rendered by client-side code:

The attack vectors come in many flavors. In the reflected XSS scenario, the attack is conducted via links that contain the malicious code. Victims click on the link, which is from a host they trust, and then interact with the altered website. Common attacks include fake login pages that send credentials somewhere else.

Figure 4 shows how reflected XSS works:

The stored flavor of XSS is even more dangerous because victims come across it unwittingly simply by using a vulnerable web application. The aforementioned XSS worms are examples of stored XSS.

Preventing XSS

There is no silver bullet to prevent XSS. In fact, fixing XSS sometimes feels like playing whack-a-mole. The video below exemplifies the challenges associated with preventing this pesky bug:

Let’s dive into a few best practices that web developers should always keep in mind.

Output Encoding

Output encoding works very well for pages generated on the sever side and is quite effective in neutralizing most XSS payloads. The most common method is HTML encoding, while URL encoding can help neutralize the injection of markup in links and redirects.

Figure 5 shows how HTML encoding neutralizes XSS:

JavaScript Escaping

Escaping can prevent injection within JavaScript context by escaping single quotes.

For example: x=”-alert (1)-” becomes x=’\’-alert (1)-\”

A flavor of HTML encoding that also encodes single quotes with ‘ can also be used. This provides a more consistent approach to preventing the issue.

Safe DOM Elements

XSS in modern, rich client UIs is often made possible by unsafe handling of the document object model (DOM).

Using the innerHTML attribute, for example, allows the user input to be rendered as HTML and XSS with JavaScript events. The safe alternative is to use contentText or innerText in some versions of Internet Explorer (IE).

Use Eval and Dynamic Function Calls With Care

Pages with large JavaScript libraries may be using the eval function, which accepts a JavaScript expression as argument. Needless to say, what goes into that expression should be carefully scrutinized. The same goes for situations in which the code or page generates function names dynamically.

Enforcing the Charset

There are XSS attacks that use a different encoding, such as UTF7, for example. If the charset of the page is not enforced, the browser will default to auto detect and those payloads will execute. For example: Content-type: text/html; charset=UTF8.

Input Validation

Whitelisting can reduce the attack surface, although in some cases single quotes and tags must be allowed. If you want to allow someone named O’Brien to update his or her user profile, for example, you need to allow single quotes.

If possible, most input should be whitelisted to alphanumeric to prevent XSS and many other attacks, and special characters should only be allowed on an exception basis. This will reduce the attack surface and minimize the potential for bugs.

Blacklisting is a very bad idea because it may prevent some tools or testers from finding the issue. Others may be able to beat the rule by trying a previously unknown method. The OWASP XSS Evasion Cheat Sheet lists the staggering number of XSS attack variations.


Besides preventing the issue, there are ways to minimize it by using secure headers that most modern browsers support:

  • X-XSS-Protection: 1; mode=block enforces the browser XSS filter for some browsers; and
  • Content-Security-Policy: script-src ‘self’ prevents the loading of external scripts, which makes XSS exploitation difficult.

There are many more useful settings of the content security policy, including options to log violations that can indicate that an attacker is leveraging a possibly unknown XSS on the site.

XSS Is Here to Stay

XSS is a pesky, ubiquitous and very dangerous type of programming flaw. Developers should always keep XSS in mind when building today’s flashy web applications. The web has become the choice for implementing attractive, platform-independent applications, and it is here to stay. Unfortunately, so is the threat of XSS.

Access Your Complimentary Trial

More from Application Security

Critically close to zero(day): Exploiting Microsoft Kernel streaming service

10 min read - Last month Microsoft patched a vulnerability in the Microsoft Kernel Streaming Server, a Windows kernel component used in the virtualization and sharing of camera devices. The vulnerability, CVE-2023-36802, allows a local attacker to escalate privileges to SYSTEM. This blog post details my process of exploring a new attack surface in the Windows kernel, finding a 0-day vulnerability, exploring an interesting bug class, and building a stable exploit. This post doesn’t require any specialized Windows kernel knowledge to follow along, though…

Gozi strikes again, targeting banks, cryptocurrency and more

3 min read - In the world of cybercrime, malware plays a prominent role. One such malware, Gozi, emerged in 2006 as Gozi CRM, also known as CRM or Papras. Initially offered as a crime-as-a-service (CaaS) platform called 76Service, Gozi quickly gained notoriety for its advanced capabilities. Over time, Gozi underwent a significant transformation and became associated with other malware strains, such as Ursnif (Snifula) and Vawtrak/Neverquest. Now, in a recent campaign, Gozi has set its sights on banks, financial services and cryptocurrency platforms,…

Vulnerability management, its impact and threat modeling methodologies

7 min read - Vulnerability management is a security practice designed to avoid events that could potentially harm an organization. It is a regular ongoing process that identifies, assesses, and manages vulnerabilities across all the components of an IT ecosystem. Cybersecurity is one of the major priorities many organizations struggle to stay on top of. There is a huge increase in the number of cyberattacks carried out by cybercriminals to steal valuable information from businesses. Hence to encounter these attacks, organizations are now focusing…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today