HTTP Splitting Smuggling

Check List

Methodology

Black Box

HRS With Content-Length And Transfer-Encoding

1

Inject conflicting Content-Length and Transfer-Encoding headers to test for desync

POST /path HTTP/1.1
Host: target.com
Content-Length: 50
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
2

Check if the response indicates the backend processed the smuggled GET /admin request

HTTP/2 To HTTP/1.1 Downgrade

1

If the site supports HTTP/2, force a downgrade to HTTP/1.1 with a smuggling payload

POST /path HTTP/2
Host: target.com
Transfer-Encoding: chunked
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
2

Verify if the backend executes the smuggled GET /admin request

Multi-Chunked Smuggling

1

Inject multiple Transfer-Encoding headers to confuse proxy parsing

POST /path HTTP/1.1
Host: target.com
Transfer-Encoding: chunked
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
2

Check if the smuggled request is processed by the backend

Invalid TE Header Manipulation

1

Use malformed Transfer-Encoding headers to bypass validation

POST /path HTTP/1.1
Host: vulnerable.com
Transfer-Encoding: cHuNkEd
Content-Length: 60

0
GET /admin HTTP/1.1
2

Verify if the response includes evidence of the smuggled request

Cache Poisoning With HRS

1

Inject a payload to poison the CDN cache

2

Check if the cache serves evil.js to subsequent users

SSRF With HRS

1

Smuggle a payload to access internal services

2

Verify if the response contains internal metadata (AWS metadata)

WAF Bypass With HRS

1

Split payloads to evade WAF detection

2

Check if the smuggled request bypasses the WAF and reaches the backend

Blind HRS

1

Inject a time-delayed payload to detect blind smuggling

2

Measure response delays to infer smuggling success

Multi-Hop Proxy Smuggling

1

Inject payloads across a chain of proxies (CDN → Load Balancer → Backend)

2

Trace the smuggled request across each hop and check for discrepancies in processing

Basic CRLF Injection

1

Modify the query parameter by injecting a CRLF sequence to add a custom header

2

Check the response headers for the injected Set-Cookie: crlf=injected. If present, the endpoint is vulnerable

The important thing is that if you inject the payload and get a 400 in response, it can indicate that the server is vulnerable, but if it gives a 404 in response, it means that the server is not vulnerable

Cookie Injection

1

Inject a CRLF sequence to manipulate cookies

2

Verify if the response includes the injected cookie (hacked=true) or affects session behavior

Redirection/phishing

1

CRLF Injection can be used to inject links that redirect users to phishing sites

2

Observe if the browser redirects to phishing page

Open Redirect

1

Inject a Location header to redirect to a malicious site

2

Observe if the browser redirects to https://evil.com

HTTP Response Splitting

1

By injecting %0d%0a (Carriage Return + Line Feed), an attacker can split the server’s HTTP response into two parts. This enables manipulation of headers and body content in unexpected ways

2

%0d%0a → Ends the current header line and A new HTTP/1.1 200 OK response starts with a malicious script in the body

Test XSS Protection Bypass

1

Inject a payload to disable XSS protections and execute JavaScript

2

Verify if the response includes X-XSS-Protection: 0 and the script executes

Test GBK-Encoded CRLF Bypass

1

If standard CRLF payloads are blocked, use GBK-encoded characters

2

Check if the response includes the injected Set-Cookie: crlfinjection=unk9vvn

CRLF Injection Using cURL

1

Test for CRLF Injection using cURL

2

Check the response headers for set-cookie: crlf=injected

White Box

Cheat Sheet

PreviousIncubated VulnerabilityNextHTTP Incoming Requests

Last updated