Log In
Request Demo Start 30-Day Trial
Back
Glossary Glossary

CWE-79 (Cross-Site Scripting)




CWE-79, also known as Cross-Site Scripting (XSS), is a software weakness that allows threat actors to inject malicious scripts into legitimate and trusted websites. 

An attack on CWE-79 exploits a web application’s trust in user-supplied data. When a web application does not properly sanitize, validate, or encode user input before rendering it in a web page, an attacker can inject client-side scripts into the content.

CWE-79 is the official umbrella classification for all Cross-Site Scripting (XSS) issues, which contribute to an organization’s growing attack surface. It falls under the OWASP Top 10 Vulnerabilities, specifically A03:2021-Injection, along with CWE-20 Improper Input Validation and CWE-94 Improper Control of Generation of Code, among other weaknesses that enable attackers to inject and execute malicious code into applications.

Table of Contents

CWE-79: Improper Neutralization of Input During Web Page Generation 

How CWE-79 (XSS) Attacks Work

A CWE-79 attack begins with the attacker identifying a vulnerable part of a web application where user input is displayed back to the user without proper sanitization. This could be a search bar, a comment section, a user profile field, or even a URL parameter.

The attacker then creates a malicious script (designed to either steal cookies, deface websites, or redirect users) and injects it into the vulnerable app using the CWE-79 vulnerability.

When the victim’s browser loads the vulnerable page, it encounters the injected script. Because the script appears to originate from the trusted website, the browser executes it with the same permissions as the legitimate website’s scripts.

Types of Cross-Site Scripting Attacks

XSS attacks can be grouped into three types: reflected XSS, stored XSS, and DOM-based XSS. Some of these have their own, more granular CWEs. 

Reflected XSS 

Reflected XSS attacks occur when actors take user input from an HTTP request and immediately include it in the web pages they send back to the user. The browser then executes this unsanitized input as if it were part of the page’s original code.

One way attackers execute reflected XSS is by exploiting CWE-81: Improper Neutralization of Script in an Error Message Web Page, which is a child of CWE-79.  Imagine a website where you can search for products. If you type in an invalid product ID (generating the URL http://onlinegadgetstore[.]com/product?id=12345), the site should display an error message that looks like this: 

"Error: Product ID 12345 not found."

However, if the application is vulnerable, an attacker can craft a URL that injects a script into the ID parameter. So when the server processes this invalid ID, it includes the script directly in the error message it generates. For instance, an attacker could craft this URL:

http://onlinegadgetstore.com/product?id=<script>alert("Malicious script executed!");</script>

When a user clicks this link, the server receives the malicious ID, but instead of just displaying “Error: Product ID <script>alert(“Malicious script executed!”);</script> not found,” the server’s flawed error handling incorporates the script directly into the HTML of the error page. The user’s browser then executes the embedded JavaScript code.

Stored XSS

This is a more dangerous type of XSS attack, also called Persistent XSS. When a web application has this weakness, an attacker can inject a script into an application feature that stores user input, such as a database, comment section, forum post, or user profile. All it takes is for a user to visit web pages displaying this stored content, and the malicious script is retrieved from the server and executed by the user’s browser.

In an HTML injection attack exploiting CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (a subtype of CWE-79), for example, an attacker can post a forum comment containing:

<script>fetch('/api/user/profile').then(res=>res.json()).then(data=>console.log(data));</script> 

Any user viewing the forum post will have the script executed, potentially revealing their profile data to the attacker.

DOM-Based Cross-Site Scripting

DOM XSS is unique because it exists entirely within the client-side code that processes data from the Document Object Model (DOM) without proper sanitization. Attackers exploit client-side scripts that read data from the URL (e.g., hash fragment # or query string) and write it back into the HTML of the vulnerable page. The malicious payload does not require interaction with the server. 

Unlike the other types of CWE-79 attacks, there’s no single dedicated CWE that can be mapped to DOM-based cross-site scripting. Instead, it is generally categorized under CWE-79, with related CWEs such as CWE-20 (Improper Input Validation) and CWE-116 (Improper Encoding or Escaping of Output) sometimes applicable depending on the context.

What Are the Reasons Behind CWE-79?

CWE-79 primarily stems from the insufficient implementation of security best practices during the development of a webpage. The root causes of this OWASP Top 10 vulnerability are usually the following:

  • Lack of input validation: Applications are not configured to thoroughly validate and filter user input before processing or displaying it. For example, the name field should only accept alphabetic characters, but users can actually input script tags.
  • No proper encoding: Even if input is validated, if the output (the data displayed back to the user) isn’t properly encoded, the browser might interpret parts of the data as executable code rather than plain text. For example, converting characters like < to &lt; and > to &gt; prevents the browser from interpreting them as HTML tags.
  • Improper context handling: Different parts of a page (HTML, JavaScript, CSS, URL) require different types of encoding. For example, HTML encoding (such as converting < to  &lt;) is fine for text nodes, but attributes, URLs, or JavaScript contexts require a different set of rules. Developers sometimes assume one “universal” encoding is enough, which leads to vulnerabilities.

What Are the Potential Impacts of CWE-79?

When CWE-79 is exploited, it can lead to damaging consequences that affect end users and the compromised organization. The potential impacts can be categorized into the following:

  • Session hijacking: A remote attacker can steal a user’s session cookies to gain access to their account and impersonate them without needing their login credentials. This can lead to account takeover and unauthorized transactions.
  • Data theft and exposure: Malicious scripts can read and exfiltrate sensitive information displayed on the page, including personally identifiable information (PII), financial details, and other confidential user or organizational data.
  • Unauthorized actions on behalf of the user: The attacker’s script can perform actions as if they were the legitimate user, such as changing passwords, making purchases, sending messages, or modifying user settings, all within the context of the authenticated user’s session.
  • Malware delivery: XSS can be used as an attack vector to force the user’s browser to download or execute malicious software, leading to system compromise, the installation of Trojan programs, and other malware attacks.
  • User redirection: Attackers can redirect users to phishing sites or other malicious websites designed to steal credentials or distribute malware.
  • Website defacement and reputation damage: In some cases, XSS can be used to alter the visual content of a website. Website defacement erodes user trust and damages brand reputation. It can also lead to significant financial and legal repercussions, particularly in relation to data privacy regulations.

How to Detect CWE-79

Detecting CWE-79 requires a combination of manual and automated techniques, such as:

  • Manual code review, focusing on areas where user-controllable input is allowed.
  • Manual testing of forms and URL parameters by injecting XSS payloads into input fields, URL parameters, HTTP request headers, and other data entry points. Observe the application’s response and the browser’s behavior for any unexpected script execution.
  • Using dynamic analysis tools like OWASP ZAP or Burp Suite, or exposure management solutions like Attaxion that automate running ZAP across all your web applications.

Protecting Against CWE-79

Below are some security measures that can help prevent CWE-79 exploitations.

1. Continuous Monitoring

Regularly scan and monitor your web applications for new security vulnerabilities. As applications evolve, new injection points can inadvertently be introduced. 

2. Educate Developers

Conduct comprehensive training for both new and seasoned developers on secure coding practices, proper input/output handling, understanding XSS, and new attack methods that leverage XSS. Since XSS is among the OWASP Top 10 vulnerabilities, the organization has created an XSS Prevention Cheat Sheet designed to help developers avoid XSS.

3. Use Contextual Output Encoding

Never trusting user input is the most effective defense against XSS. Always encode data before rendering it on an HTML page. The type of encoding strategy depends on where the data is being placed (e.g., HTML entity encoding for HTML content, JavaScript escaping for JavaScript contexts, URL encoding for URL parameters). 

4. Limit User Inputs

Implement strict input validation on the server-side. Restrict user input to only what is absolutely necessary (e.g., enforce maximum lengths, use allow-lists for characters, validate data types).

5. HttpOnly Flags for Cookies

Set the HttpOnly flag on cookies that do not need to be accessed by client-side scripts to prevent malicious JavaScript from reading or stealing session cookies, even if an XSS vulnerability exists.

6. Content Security Policy (CSP)

CSP acts as an additional layer of security that allows web administrators to specify which dynamic resources (i.e., scripts, stylesheets, etc.) can be loaded and executed on a given page, thereby mitigating the effects of injected scripts.

7. Use a Web Application Firewall (WAF)

A WAF can provide an additional layer of protection by filtering and monitoring HTTP traffic between a web application and the internet. WAFs can detect and block known XSS attack patterns, though they are not a substitute for secure coding practices and may not catch all sophisticated XSS attacks.

Key Takeaways

  • CWE-79, or Cross-Site Scripting (XSS), is a category of web vulnerabilities that allow attackers to inject malicious scripts into trusted websites, which are then executed by a victim’s browser.
  • It stems from a failure to neutralize user-supplied input before it’s rendered on a webpage.
  • It is a major injection flaw listed under A03:2021-Injection in the OWASP Top 10 vulnerabilities, contributing to an organization’s attack surface expansion.
  • The three main types are Reflected XSS, Stored XSS, and DOM-based XSS.
  • An attack exploiting CWE-79 can lead to session hijacking, data theft, unauthorized actions on behalf of the user, and malware delivery.
  • The most effective defense is contextual output encoding and strict input validation. This ensures all user-supplied data is treated as plain text and can’t be executed as code.

Schedule a free demo now to see how Attaxion detects CWE-79 and other CWEs in your organization’s external attack surface.