Cross-Site Scripting (XSS)

XSS (cross-site scripting) is a type of cyberattack in which the threat actor injects malicious scripts into websites and web applications. The goal is to have these scripts executed on the users’ end-point devices where the threat actors can bypass controls and impersonate users. XSS attacks turn a harmless website or web application into an attack vector to deliver malicious scripts to the web browsers of unsuspecting victims. The goal of the attack is to steal cookies, session identifiers, names, and passwords.

A brief history of XSS

In 1999 the Microsoft Security Response Center and the Microsoft Internet Explorer Security Team had gathered data on several website attacks where script and image tags were maliciously injected into HTML pages. Microsoft engineers researched the vulnerability and in 2000 published the first of many reports on the exposure. In conjunction with CERT, this first article gave the attack the name cross-site scripting (XSS).

Many programming environments and languages can be at risk, including Flash, ActiveX, JavaScript, and VBScript. For example, javaScript is frequently run on the web pages within your browser, and hackers commonly target JavaScript due to its close integration with most browsers. Because of the popularity of these programming languages, they are frequently the target of cyber-attacks; hence making XSS an ongoing and continuing attack vector threat.

Types of XSS attacks

There are three primary attack strategies for XSS. They are DOM-based XSS, reflected XSS, and stored XSS. 

DOM Based XSS.  In a DOM-based XSS attack strategy, the hacker injects the payload by modifying the document object model (DOM) in the victim’s browser, where the original client script is running. The page doesn’t change, but the client-side code contained in the page runs with the malicious code modifications. 

Reflected XSS. In a reflected XSS cyberattack, the threat actor injects the malicious script directly into an HTTP request.  Then it is reflected from the webserver to the user’s browser, where it is executed. Frequently, the threat actor will send the targeted victims customized links that bring them to a vulnerable page. 

Reflected XSS attacks are not persistent. When a user is tricked into clicking a malicious link, submitting a specially crafted form, or browsing a malicious site, the injected code travels to the vulnerable website. The Web server, in turn, returns or reflects the injected script to the user’s browser. This deception may happen in an error message, search result, or some other type of response that includes data sent to the server as part of the request. The browser executes the code because it assumes the response is from a “trusted” server with which the user has already interacted.

A specific example might be when a threat actor places malicious javascript in the search field within a website form. In the normal case, the input would appear this way:

In this case malicious javascript is placed in the input string:

Stored XSS. Attacks occur once the threat actors store their payload on a compromised server.  Stored XSS attacks are persistent and happen when the server saves the data provided by the attacker and then presented on other pages returned to browsing users but without proper HTML escaping. This action results in the website delivering the malicious code to additional victims when the browser requests data. 

If an application stores tagged data on the server, there may be insufficient protection to stop a threat actor from storing compromised data within an application.

As an example, think of a simple bulletin board application. The threat actor stores the malicious code in a field that another user may browse, click and retrieve. When a user clicks the field, the embedded script will instantaneously grab the cookie. The threat actor’s malicious server will instantly transmit it via email since this user session is active and stored in the cookie. Now it is the digital identity for this user. The threat actor can load the cookie, do everything the user can do, and see everything they can see. Since the threat actor is now validated, the server believes the requests come from the user. Meanwhile, the user has no idea this is happening. 

The malicious hidden code might appear this way where the threat actor checks on the results of their baddog.php cookie stealer script. Then, as noted earlier, they can assume the user’s identity and hijack their session with the session cookie.

Best practices to prevent XSS attacks

Picklists for allowable user input. Picklists ensure that only safe and expected values are sent to the server. Picklists won’t work when you have custom user content. 

Implement a content security policy (CSP). CSP is another layer of security that can help mitigate XSS attacks. To enable CSP, you should configure your webserver to return the content-security-policy HTTP header. 

Use a web application firewall (WAF). A WAF will monitor, filter, and analyze HTTP and HTTPS traffic between web applications and the internet. In addition, the WAF will filter out dangerous or malicious requests. WAFs protect against cross-site scripting, zero-day SQL injection, and other application-layer attacks. 

Scrubbed (sanitized) input fields. User-generated content should not be rendered as HTML. Validate any information input by users in the data fields.

Software updates. Keeping your software up to date can eliminate or reduce website or application XSS vulnerabilities.

Also, refer to the Common Weakness Enumeration for additional information on XSS. The 2021 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses (CWE Top 25) comprehensively lists the most common threat actor issues experienced over the previous two years. Note that in 2021 XSS is ranked as the number 2 overall weakness identified.

Per cwe.mitre.org, to create the 2021 list, the CWE Team leveraged Common Vulnerabilities and Exposures (CVE®) data found within the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD), as well as the Common Vulnerability Scoring System (CVSS) scores associated with each CVE record. A formula was applied to the data to score each weakness based on prevalence and severity.