@gpzhang2001/sharpkit-skills 0.2.1

package/skills/vulnerabilities/header_injection.md

@@ -0,0 +1,216 @@
+---
+name: header-injection
+description: HTTP header injection testing covering CRLF / response splitting, cache poisoning, Host-header confusion, cookie fixation, and proxy / forwarding header smuggling
+---
+
+# HTTP Header Injection
+
+Header injection turns user input into protocol-level control: response splitting, cache poisoning, session fixation, authentication bypass, and downstream parser confusion can trace back to a server-controlled header value that was not normalized. The bug usually lives in middle layers — frameworks that copy a request value into a response header, proxies that trust forwarded headers, caches keyed on something the attacker influences. Impact depends on which downstream component consumes the injected field and how.
+
+## Attack Surface
+
+**Input shapes that reach headers**
+- Query/body/path values echoed into `Set-Cookie`, `Location`, `Content-Type`, `Content-Disposition`, `Link`, custom `X-*`
+- Request headers re-emitted into responses (Referer, User-Agent, X-Forwarded-*, custom correlation IDs)
+- Webhook / callback flows where the server constructs outbound requests using user-supplied URLs (Host, Referer)
+- Outbound email headers (To/From/Subject) populated from user input
+
+**Code patterns that enable injection**
+- Direct concatenation of user input into header values without CR/LF stripping
+- Frameworks that accept header values as strings and serialize verbatim (no normalization)
+- Proxy chains trusting `X-Forwarded-*` / `Forwarded` / `X-Real-IP` set by an upstream that anyone can spoof
+- `X-HTTP-Method-Override` and similar method-shaping headers respected past auth layers
+
+**Transports and parser layers**
+- HTTP/1.0, HTTP/1.1, HTTP/2, HTTP/3 each parse framing differently
+- CDN / reverse proxy → application server (where each side may disagree on framing)
+- Chunked transfer encoding boundaries and multipart/form-data delimiters
+
+## High-Value Targets
+
+- Password-reset and account-recovery flows (Host header determines the link sent to the user)
+- OAuth / SSO redirect endpoints (`Location`, `redirect_uri` echoes)
+- Auth gateways that trust `X-Forwarded-For` / `X-Real-IP` for IP allowlists or rate limits
+- CDN / WAF caches (poisoning a public cache with a per-user response)
+- Multi-tenant routing keyed on Host or `X-Tenant-Id`
+- File-download endpoints (`Content-Disposition` filename derived from user input)
+- Outbound notification / email systems where user input lands in the message header
+
+## Reconnaissance
+
+### Header Inventory
+
+- Enumerate every response header that varies with input — flip query / body / cookie values and diff `Set-Cookie`, `Location`, `Content-Type`, `Content-Disposition`, `ETag`, `Vary`, custom `X-*`
+- For each varying header, identify the source field (user-controlled vs. server-derived)
+- Look for request headers reflected into responses (Referer in error pages, User-Agent in correlation IDs, X-Forwarded-Host echoed back)
+
+### CR/LF and Whitespace Variants
+
+- Bare LF (`%0a`), bare CR (`%0d`), CRLF (`%0d%0a`)
+- Double encoding (`%250d%250a`) for WAFs that decode once
+- Overlong UTF-8 of CR/LF (`%c0%8d`, `%c0%8a`) — invalid per spec but accepted by some parsers
+- Unicode line/paragraph separators (`%e2%80%a8` U+2028, `%e2%80%a9` U+2029) — sometimes folded to LF by intermediaries
+- Tab (`%09`) — RFC 7230 allows tabs in field values, useful for sneaking past simple `\s+` filters
+- Null byte (`%00`) — can truncate the header value in some parsers
+
+### Parser and Server Fingerprinting
+
+- `Server`, `Via`, `X-Powered-By`, `X-AspNet-Version`, `X-Served-By`, `CF-Ray`, `X-Amzn-RequestId` reveal the stack
+- `Vary`, `Age`, `X-Cache`, `CF-Cache-Status` reveal caching layer and key composition
+- Same payload over HTTP/1.1 vs HTTP/2 vs chunked — diff status, headers, body length to map parsing differences
+- Compare `Host` and `X-Forwarded-Host` precedence: send both with different values and observe which wins in redirects, links, log entries
+
+## Key Vulnerabilities
+
+### CRLF Response Splitting
+
+Inject `\r\n\r\n` to terminate the current response and prepend a second attacker-controlled response. Cache or downstream proxy may key on the first response and serve the second to other users.
+
+```
+GET /redirect?to=foo%0d%0aSet-Cookie:%20admin=1%0d%0a%0d%0a<html>poisoned</html> HTTP/1.1
+```
+
+Request smuggling is a separate request-boundary vulnerability involving disagreement between two HTTP parsers, not simply response header injection at the request layer. Load `http_request_smuggling` when conflicting lengths, transfer coding, HTTP/2 downgrades, or connection desynchronization are in scope.
+
+### Cache Poisoning
+
+- **Unkeyed input → keyed response**: input that influences the response body but not the cache key (an `X-Forwarded-Host` echoed in a link, an unkeyed query parameter reflected in HTML)
+- **`Vary` manipulation**: inject a `Vary` header to over-fragment the cache (DoS-flavored) or under-fragment it (cross-user serving)
+- **`X-Forwarded-Proto` / `X-Forwarded-Host` poisoning**: backend uses these to build canonical URLs in the response; CDN caches the response with attacker-controlled links
+- **`Cache-Control` injection**: flip `private` to `public` (or vice versa) to change cache eligibility; inject `max-age=999999` for persistent poisoning, or `max-age=0` / `no-cache` to flush — `Age` is generated by the cache itself and isn't a freshness control, don't bother with it
+- **Web cache deception**: trick the cache into storing an authenticated response at a public-looking URL (`/account/profile.css`) by appending a cacheable extension
+
+### Host Header Confusion
+
+Backends often trust `Host` (or `X-Forwarded-Host`) when constructing absolute URLs — password reset emails, OAuth `redirect_uri`, canonical link tags. Sending a forged Host produces a reset link pointing at attacker-controlled infrastructure that still carries the victim's reset token.
+
+```
+POST /password-reset HTTP/1.1
+Host: attacker.tld
+```
+
+Also test: precedence between `Host` and `X-Forwarded-Host`, IPv6 bracketing (`Host: [::1]:80`), trailing dot (`Host: example.com.`), and port confusion (`Host: example.com:@attacker.tld`).
+
+### Cookie / Set-Cookie Manipulation
+
+- Inject `Domain=.example.com` or `Path=/` to widen scope of an attacker-set cookie
+- Inject `SameSite=None; Secure` to allow cross-site inclusion
+- Inject `Max-Age=999999999` for persistence, or `Max-Age=-1` to nuke the victim's session
+- Inject a cookie with the same name as a real session cookie — precedence rules let a same-domain attacker shadow it (cookie tossing)
+- Reflected cookie XSS: if a cookie value is later rendered unescaped in HTML, the injection point is the header but the sink is the page
+
+### Proxy and Forwarding Header Spoofing
+
+The `X-Forwarded-*` family is informational — there is no protocol guarantee about who set them. Any application that trusts them past the boundary it controls is exploitable.
+
+- `X-Forwarded-For: 127.0.0.1` to bypass IP allowlists or rate limits keyed on client IP
+- `X-Forwarded-Proto: https` to satisfy "HTTPS-only" checks while still using HTTP
+- `X-Forwarded-Host: attacker.tld` for the Host-confusion variants above
+- `X-Real-IP`, `Client-IP`, `True-Client-IP`, `CF-Connecting-IP`, `Forwarded` (RFC 7239) — same trust class under different conventions; select evidence-supported variants for the observed proxy/CDN stack
+- `X-Original-URL` / `X-Rewrite-URL` (IIS, ASP.NET) — server-side URL rewriting after auth check, classic admin-panel auth bypass
+
+### Content-Type / Encoding Confusion
+
+- Inject `Content-Type: text/html` into an endpoint that returned JSON; browsers may sniff and render → XSS
+- Inject `Content-Disposition: inline` to switch a download into in-page rendering
+- *Absence* of `X-Content-Type-Options: nosniff` is what enables the sniffing attacks above; the header is a hardening control, not an attack surface — but if a server sets it inconsistently across endpoints, target the ones that don't
+- Compare MIME validators with browser parsing of duplicate or comma-joined `Content-Type` values. Record first/last valid member behavior and invalid-parameter recovery for each consumer.
+
+### Internal Redirect and Handler Confusion
+
+- Determine whether CGI/FastCGI/WSGI-style response headers can trigger an internal redirect instead of an external response.
+- Trace which request fields survive the redirect: content type, handler, method, authorization result, path, and environment.
+- Test whether response metadata is reused as an internal handler, proxy target, template type, or interpreter selection.
+- Compare direct access controls with the internally dispatched resource. A protected URL may be unreachable directly while the same handler is invokable through a clean internal redirect.
+- Treat CRLF injection and response-controlling SSRF as possible inputs to this chain, then validate handler selection before using a privileged handler.
+
+### XSS via Response Headers
+
+- `Location: javascript:alert(1)` if redirect target is reflected unescaped (browsers usually block, but some legacy clients and Electron-style hosts don't)
+- `Location: data:text/html,<script>alert(1)</script>` — same caveat
+- `Refresh: 0; url=javascript:alert(1)` — the legacy `Refresh` header is a JavaScript-free meta-refresh equivalent
+- Reflected request header XSS: `Referer` echoed into a custom error page, `User-Agent` echoed into a debug header — combine CRLF injection with a body-injection sink
+
+### Open Redirect via Headers
+
+- `Location` is the obvious one
+- `Refresh: 0; url=https://attacker.tld` — bypasses some `Location`-only filters
+- `Link: <https://attacker.tld>; rel="canonical"` — usually informational but consumed by SEO tooling and some clients
+- `X-Accel-Redirect: /internal/file` (Nginx) — if user input reaches this, internal-only files become accessible
+
+### HTTP/2 Pseudo-Header and Frame Confusion
+
+- HTTP/2 splits headers into pseudo-headers (`:method`, `:path`, `:authority`, `:scheme`) and regular fields. Servers downgrading to HTTP/1.1 sometimes mishandle pseudo-header values, enabling smuggling across the H2 → H1 boundary.
+- HTTP/2 lowercases header names; an upstream H1 filter that's case-sensitive may miss a lowercase variant that the H2 backend then accepts.
+- HEADERS / CONTINUATION frame splitting: payload spans frames, intermediaries differ on whether they reassemble before applying filters.
+
+## Bypass Techniques
+
+**Encoding**
+- URL-encode (`%0d%0a`) and double-encode (`%250d%250a`) for WAFs that decode the wrong number of times
+- Mix encodings within one payload: `%0d%0A`, `%0D\n`, alternating case
+- Newline-equivalent Unicode: U+2028 / U+2029 (sometimes folded to LF), overlong UTF-8 of CR/LF
+
+**Header normalization edges**
+- Leading / trailing whitespace and tabs in header names and values
+- Header folding (obs-fold per RFC 7230 — formally obsolete, but some parsers still accept continuation lines starting with whitespace)
+- Duplicate headers — RFC says join with `,`; in practice servers pick first, last, or differ from the proxy in front of them
+
+**Method and method-override**
+- `X-HTTP-Method-Override: PUT` (and `X-Method-Override`, `X-HTTP-Method`) to reach state-changing handlers when the framework consults the override before applying method-based authorization
+- Effective from server-side or non-browser clients (curl, internal tooling, server-to-server proxies); from a browser the header is non-safelisted and triggers a CORS preflight, so it isn't a CSRF primitive on its own
+
+**Header name games**
+- Case mangling for filters that key off exact casing
+- Null byte truncation in header name (`X-Forwarded-For\x00Evil`) on parsers that stop at NUL
+
+## Testing Methodology
+
+1. **Inventory varying headers** — enumerate every response header whose value moves with input
+2. **Probe CR/LF normalization** — inject `%0d%0a` (and the encoding variants) into each varying header source; observe whether the second line lands as a real header
+3. **Test Host / X-Forwarded-Host** — submit a password-reset or any link-generating flow with attacker-controlled Host; confirm the link in the response or follow-up email
+4. **Probe forwarding headers** — spoof `X-Forwarded-For`, `X-Real-IP`, `True-Client-IP`, `CF-Connecting-IP` against IP-restricted endpoints (admin, rate-limited)
+5. **Test cache key / response content split** — find inputs that change the body but not the cache key; confirm a second request from a different session sees the poisoned response
+6. **Test method override** — `X-HTTP-Method-Override` paired with state-changing endpoints reachable via POST or GET
+7. **Route framing discrepancies** — if evidence indicates request-boundary disagreement, switch to `http_request_smuggling`
+8. **Cross-protocol** — replay payloads over HTTP/1.1 and HTTP/2; diff behavior
+9. **Trace internal reprocessing** — where response headers can cause subrequests/internal redirects, diff retained fields and final handler selection
+
+## Validation
+
+1. Show two distinct users (or sessions) receiving content keyed on attacker-supplied header — proves cache poisoning
+2. Capture a password-reset / OAuth link pointing at attacker-controlled host — proves Host injection
+3. Demonstrate the same endpoint returning different auth decisions with and without a forged forwarding header
+4. For response splitting: show a downstream cache or proxy serving the injected second response to an unrelated request
+5. All findings should produce a durable artifact (cached response, sent email, log entry, session change) — transient anomalies are not validation
+6. For internal redirects, capture both the injected response metadata and the final internally selected route/handler
+
+## False Positives
+
+- Headers that vary by input but are correctly keyed in the cache (intentional personalization, Vary set correctly)
+- `X-Forwarded-*` reflected back but only used for logging — not a security boundary, may not be exploitable
+- Browsers blocking `Location: javascript:` or `Location: data:` — capability exists in the protocol but most modern browsers refuse to navigate
+- CRLF appearing in response headers but stripped by an outer proxy before reaching any client or cache
+
+## Impact
+
+- Cross-user cache poisoning (defacement, XSS, account takeover via cached auth response)
+- Account takeover via Host-confused password-reset / OAuth flows
+- Auth bypass on endpoints trusting forwarding headers
+- Session fixation and cookie tossing leading to account hijack
+- Open redirect for phishing / OAuth `redirect_uri` abuse
+- WAF / detection bypass via header-name and encoding tricks
+
+## Pro Tips
+
+1. The fastest win is usually Host / `X-Forwarded-Host` in a password-reset or OAuth flow — try first, costs one request
+2. For cache poisoning, find the *unkeyed* input first (header that influences body but not cache key); the rest follows
+3. `X-HTTP-Method-Override` is high-yield against backends that route on it before checking method-based auth — most useful from server-side / non-browser callers (it triggers CORS preflight in a browser, so not a CSRF primitive)
+4. If a header test exposes message-boundary disagreement, switch to the dedicated request-smuggling workflow and identify the proxy → backend pair
+5. `X-Original-URL` / `X-Rewrite-URL` against IIS / ASP.NET admin endpoints is still a high-yield bypass
+6. Before claiming a CRLF win, verify the second line landed as a real header in the cache or downstream consumer — many servers strip CRLF silently
+7. Outbound email flows are a separate but related surface — user input flowing into SMTP headers (To, Cc, Subject, Reply-To) is its own injection class with the same root cause
+
+## Summary
+
+Header injection is fundamentally a normalization failure: somewhere on the request → response path, user input reached a header value without CR/LF stripping or proper escaping. The impact tiers up from open redirect to cache poisoning to request smuggling depending on which downstream component trusts the resulting header. Audit every header whose value moves with input, and treat every `X-Forwarded-*` / Host trust as a security boundary that needs explicit justification.

package/skills/vulnerabilities/http_request_smuggling.md

@@ -0,0 +1,255 @@
+---
+name: http-request-smuggling
+description: HTTP request smuggling testing covering CL.TE, TE.CL, H2.CL, H2.TE, and HTTP/2 desync techniques with practical detection and exploitation methodology
+---
+
+# HTTP Request Smuggling
+
+HTTP request smuggling (HRS) exploits disagreements between a front-end proxy and a back-end server about where one HTTP request ends and the next begins. When the two systems parse `Content-Length` and `Transfer-Encoding` headers differently, an attacker can prefix a hidden request to the back-end's socket, which is then prepended to the next legitimate user's request. The impact ranges from bypassing front-end security controls to full cross-user session hijacking.
+
+## Attack Surface
+
+**Infrastructure Topologies**
+- CDN or load balancer in front of origin server (Cloudflare, Nginx, HAProxy, AWS ALB)
+- Reverse proxy chains (Nginx → Gunicorn, HAProxy → Node.js, Varnish → Apache)
+- API gateways forwarding to microservices
+- HTTP/2 front-end to HTTP/1.1 back-end translation (H2.CL / H2.TE)
+- Tunneling servers or WAFs that terminate and re-forward requests
+
+**HTTP Versions in Play**
+- HTTP/1.1: CL.TE and TE.CL classic smuggling
+- HTTP/2: H2.CL (downgrade injects Content-Length) and H2.TE (injects Transfer-Encoding)
+- HTTP/3: emerging QUIC-based desync (less common, research-stage)
+
+**Parser Differentials**
+- Treatment of duplicate `Content-Length` headers
+- Handling of `Transfer-Encoding: chunked` when `Content-Length` is also present
+- Chunk size obfuscation via whitespace, tab, case, or invalid extensions
+
+## High-Value Targets
+
+- Front-end security controls (authentication bypass via desync)
+- Endpoints shared by many users (high-traffic APIs, chat, feeds)
+- Request capture endpoints (search, logging, analytics)
+- Session-sensitive endpoints (auth callbacks, account settings)
+- Internal admin interfaces proxied through the same connection pool
+
+## Core Concepts
+
+### CL.TE — Front-end uses Content-Length, Back-end uses Transfer-Encoding
+
+Front-end reads `Content-Length: X` bytes and forwards. Back-end reads until the `0\r\n\r\n` chunk terminator. Attacker appends a hidden request after the `0` terminator that the front-end considers part of the same body but the back-end treats as a new request.
+
+```http
+POST / HTTP/1.1
+Host: target.com
+Content-Length: 6
+Transfer-Encoding: chunked
+
+0
+
+G
+```
+The `G` is left in the back-end's socket buffer and prepended to the next request.
+
+### TE.CL — Front-end uses Transfer-Encoding, Back-end uses Content-Length
+
+Front-end reads chunked body to completion. Back-end reads only `Content-Length` bytes, leaving the remainder on the socket.
+
+```http
+POST / HTTP/1.1
+Host: target.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 3
+Transfer-Encoding: chunked
+
+8
+SMUGGLED
+0
+
+
+```
+
+### H2.CL — HTTP/2 Front-end Downgrades to HTTP/1.1, Injects Content-Length
+
+HTTP/2 has no `Content-Length` vs `TE` ambiguity in its own framing. But when the front-end downgrades to HTTP/1.1 for the back-end, an attacker can inject a `content-length` header in the HTTP/2 request that conflicts with the actual body length. Note: `content-length` is a regular HTTP/2 header — pseudo-headers are exclusively `:method`, `:path`, `:authority`, and `:scheme`:
+```
+:method POST
+:path /
+:authority target.com
+content-type application/x-www-form-urlencoded
+content-length: 0
+
+SMUGGLED_PREFIX
+```
+
+### H2.TE — HTTP/2 Injects Transfer-Encoding Header
+
+Inject `transfer-encoding: chunked` in HTTP/2 headers (which the HTTP/2 spec forbids, but some front-ends pass through). Back-end receives both headers, may prefer TE over CL.
+
+```
+:method POST
+:path /
+transfer-encoding: chunked
+
+0
+
+SMUGGLED
+```
+
+## Key Vulnerabilities
+
+### Front-End Security Control Bypass
+
+A front-end proxy enforces authentication or IP restriction by checking request headers and blocking or allowing based on rules. If a smuggled prefix bypasses the front-end (because it's buried in a prior request's body from the front-end's view), the back-end processes it without the security check.
+
+**PoC structure (CL.TE):**
+```http
+POST /not-restricted HTTP/1.1
+Host: target.com
+Content-Length: 100
+Transfer-Encoding: chunked
+
+0
+
+GET /admin HTTP/1.1
+Host: target.com
+X-Forwarded-Host: target.com
+Content-Length: 10
+
+x=1
+```
+The `GET /admin` is seen by the back-end as a new, legitimate request originating from the trusted proxy IP.
+
+### Cross-User Request Capture
+
+Poison the back-end socket with a partial request prefix that captures the next victim user's request (including their cookies, tokens, request body) into the response of a controlled endpoint (search, comment submission).
+
+**PoC structure (CL.TE capture):**
+```http
+POST /search HTTP/1.1
+Host: target.com
+Content-Length: 120
+Transfer-Encoding: chunked
+
+0
+
+POST /search HTTP/1.1
+Host: target.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 100
+
+q=
+```
+`Content-Length: 100` in the smuggled prefix is longer than the actual smuggled body, so the back-end waits for 100 bytes — which it sources from the *next* user's request. The `/search` endpoint reflects the query, capturing headers and body of the subsequent request.
+
+### Response Queue Poisoning
+
+On pipelined connections, cause a misaligned response to be delivered to the wrong user (HTTP/1.1 response queue poisoning). Used to deliver attacker-controlled content or steal another user's response.
+
+### Request Reflection / Cache Poisoning Chain
+
+Smuggle a prefix that hits a cacheable endpoint with an injected `Host` header. If the cache stores the response keyed only on URL, the poisoned response is served to all users requesting that URL.
+
+### WebSocket Handshake Hijacking
+
+If the proxy performs WebSocket upgrade, a smuggled `Upgrade` request can hijack an existing WebSocket connection from a subsequent user.
+
+## Detection Techniques
+
+### Timing-Based Detection
+
+**CL.TE:** Send a request where `Content-Length` is complete but `Transfer-Encoding` body is missing the `0\r\n\r\n` terminator. A CL.TE-vulnerable back-end waits for the terminator, causing a timeout.
+
+```http
+POST / HTTP/1.1
+Host: target.com
+Transfer-Encoding: chunked
+Content-Length: 6
+
+3
+abc
+X
+```
+If response is delayed 10–30 seconds, CL.TE desync likely.
+
+**TE.CL:** Send a request with a complete chunked body (including the `0\r\n\r\n` terminator so the front-end is satisfied) but with `Content-Length` set to **more** bytes than the body actually provides. The back-end, using Content-Length, waits for the remaining bytes that never arrive — producing a 10–30 second timeout. Setting Content-Length *less* than the body causes socket poisoning (differential-response detection), not a timeout.
+
+### Differential Response Detection
+
+Send two requests in sequence. If the second request receives an unexpected response (error, redirect, wrong content), the first may have poisoned the socket. Use a unique string in the smuggled prefix to confirm.
+
+### Content-Length + Transfer-Encoding Combination
+
+```http
+Transfer-Encoding: xchunked        # non-standard value, some FE ignore, BE accept
+Transfer-Encoding: chunked         # leading space before value (0x20 byte after colon+space)
+Transfer-Encoding:	chunked        # tab character before value
+Transfer-Encoding: x
+Transfer-Encoding: chunked         # duplicate TE headers, BE uses last
+```
+
+## Transfer-Encoding Obfuscation
+
+To force TE disagreement:
+```
+Transfer-Encoding: xchunked
+Transfer-Encoding : chunked       # space before colon
+X: X<CRLF>Transfer-Encoding: chunked # header injection — inject actual CRLF bytes at <CRLF>, not the literal string \r\n
+Transfer-Encoding: chunked<CRLF>Transfer-Encoding: x  # TE twice — inject actual CRLF bytes at <CRLF>
+```
+
+## HTTP/2-Specific Detection
+
+- Send HTTP/2 requests with an injected `content-length` regular header that differs from the actual body length
+- Inject `transfer-encoding: chunked` in HTTP/2 headers (spec-forbidden but sometimes passed through)
+- Use HTTP/2 header injection: inject newlines in header values if the front-end passes them to HTTP/1.1 back-end unescaped
+- Observe whether the HTTP/2 connection ID corresponds to a persistent HTTP/1.1 connection to the back-end (connection reuse amplifies impact)
+
+## Testing Methodology
+
+1. **Map the proxy chain** — identify front-end (CDN, load balancer, WAF) and back-end (app server)
+2. **Probe CL.TE** — send a timing probe with mismatched chunked terminator; observe delay
+3. **Probe TE.CL** — send a timing probe with complete chunked body but Content-Length larger than the actual body; observe back-end timeout
+4. **Obfuscate TE header** — try each obfuscation variant (tab, extra space, duplicate, non-standard value)
+5. **Confirm with differential response** — send two rapid identical requests; if second gets an unexpected response, socket is poisoned
+6. **Attempt bypass exploit** — craft a smuggled `GET /admin` or restricted endpoint and observe if back-end accepts it
+7. **Attempt capture** — poison with a partial POST pointing to a reflective endpoint; wait for a follow-up request to fill the buffer
+8. **Test H2.CL/H2.TE** — repeat the same probes over HTTP/2 connections if the target supports HTTP/2
+
+## Validation
+
+1. Show a timing differential of 10+ seconds on the CL.TE or TE.CL probe and explain the mechanism
+2. Demonstrate a bypass: smuggle a request to `/admin` and receive a 200 response where a direct request returns 403
+3. For capture: show a subsequent user's `Cookie` or `Authorization` header appearing in the response of a controlled endpoint
+4. Confirm with a unique marker string in the smuggled prefix to rule out timing noise
+5. Provide the exact raw bytes of the smuggled request
+
+## False Positives
+
+- General network latency or server-side processing delays unrelated to smuggling
+- Server consistently close connection after first request (no connection reuse, no socket sharing)
+- HTTP/2 with full end-to-end HTTP/2 to back-end (no HTTP/1.1 downgrade, no desync surface)
+- WAF or proxy that normalizes TE/CL headers before forwarding (removes the ambiguity)
+
+## Impact
+
+- Authentication and authorization bypass by smuggling requests past front-end access controls
+- Cross-user session hijacking by capturing requests containing session tokens
+- Cache poisoning affecting all users of a cached resource
+- Internal service access bypassing IP-based restrictions enforced at the front-end
+- XSS delivery via response queue poisoning in shared connection contexts
+
+## Pro Tips
+
+1. Use Burp Suite's HTTP Request Smuggler extension as a rapid scanner, but always confirm manually — false positives are common
+2. TE obfuscation is the most reliable path; `Transfer-Encoding: xchunked` works on many Apache/IIS back-ends
+3. Keep smuggled prefixes short during detection; use the minimal body to confirm desync before attempting capture attacks
+4. H2.CL is the most impactful modern variant — many CDNs translate HTTP/2 to HTTP/1.1 and derive `Content-Length` from the `content-length` regular header sent in the HTTP/2 request (not a pseudo-header — inject it as a normal header field)
+5. In capture attacks, set `Content-Length` in the smuggled prefix larger than your partial body by 50–100 bytes to catch a full auth header from the next user
+6. Test during low-traffic periods first to avoid affecting real users; always get explicit authorization for capture attempts
+7. If timing probes are inconsistent, pipeline two requests over the same connection and look for unexpected response swapping
+
+## Summary
+
+HTTP request smuggling is eliminated by enforcing consistent TE/CL interpretation at every hop in the proxy chain, preferring end-to-end HTTP/2, and having back-end servers reject or normalize ambiguous requests. At the proxy level, never forward TE headers that were not present in the original request, and treat conflicting CL + TE as a hard error.