Translated ['src/pentesting-web/http-request-smuggling/README.md'] to zh

src/pentesting-web/http-request-smuggling/README.md

@@ -15,7 +15,7 @@
 
 **Content-Length**
 
-> Content-Length 实体头指示发送给接收者的实体主体的字节大小。
+> Content-Length 实体头指示发送给接收者的实体主体的大小（以字节为单位）。
 
 **Transfer-Encoding: chunked**
 
@@ -33,14 +33,14 @@
 
 - **Content-Length**：此头使用**十进制数字**指示请求**主体**的**字节数**。主体预计在最后一个字符结束，**请求末尾不需要换行**。
 - **Transfer-Encoding:** 此头在**主体**中使用**十六进制数字**指示**下一个块**的**字节数**。**块**必须以**换行**结束，但此换行**不计入**长度指示器。此传输方法必须以**大小为0的块后跟2个换行**结束：`0`
-- **Connection**：根据我的经验，建议在请求欺骗的第一个请求中使用**`Connection: keep-alive`**。
+- **Connection**：根据我的经验，建议在请求 Smuggling 的第一个请求中使用**`Connection: keep-alive`**。
 
 ## 基本示例
 
 > [!TIP]
-> 在尝试使用Burp Suite进行利用时，**禁用 `Update Content-Length` 和 `Normalize HTTP/1 line endings`**，因为某些工具滥用换行符、回车和格式错误的内容长度。
+> 在尝试使用 Burp Suite 利用此漏洞时，**禁用 `Update Content-Length` 和 `Normalize HTTP/1 line endings`**，因为某些工具滥用换行符、回车和格式错误的内容长度。
 
-HTTP请求欺骗攻击是通过发送模棱两可的请求来构造的，这些请求利用前端和后端服务器在解释`Content-Length`（CL）和`Transfer-Encoding`（TE）头时的差异。这些攻击可以以不同形式表现，主要为**CL.TE**、**TE.CL**和**TE.TE**。每种类型代表前端和后端服务器如何优先处理这些头的独特组合。漏洞源于服务器以不同方式处理相同请求，导致意外和潜在的恶意结果。
+HTTP请求走私攻击是通过发送模棱两可的请求来构造的，这些请求利用了前端和后端服务器在解释`Content-Length`（CL）和`Transfer-Encoding`（TE）头时的差异。这些攻击可以以不同形式表现，主要为**CL.TE**、**TE.CL**和**TE.TE**。每种类型代表前端和后端服务器如何优先处理这些头的独特组合。漏洞源于服务器以不同方式处理相同请求，导致意外和潜在的恶意结果。
 
 ### 漏洞类型的基本示例
 
@@ -80,8 +80,8 @@ Foo: x
 - **攻击场景：**
 
 - 攻击者发送一个分块请求，其中块大小（`7b`）和实际内容长度（`Content-Length: 4`）不一致。
-- 前端服务器尊重`Transfer-Encoding`，将整个请求转发给后端。
+- 前端服务器遵循 `Transfer-Encoding`，将整个请求转发给后端。
-- 后端服务器尊重`Content-Length`，仅处理请求的初始部分（`7b`字节），将其余部分视为意外的后续请求。
+- 后端服务器尊重 `Content-Length`，仅处理请求的初始部分（`7b` 字节），将其余部分留作意外的后续请求的一部分。
 - **示例：**
 
 ```
@@ -102,14 +102,14 @@ x=
 
 ```
 
-#### TE.TE 漏洞（两者都使用Transfer-Encoding，并进行模糊处理）
+#### TE.TE 漏洞（两者都使用 Transfer-Encoding，带有混淆）
 
-- **服务器**：两者都支持`Transfer-Encoding`，但可以通过模糊处理欺骗其中一个忽略它。
+- **服务器**：两者都支持 `Transfer-Encoding`，但一个可以通过混淆被欺骗以忽略它。
 - **攻击场景：**
 
-- 攻击者发送一个带有模糊`Transfer-Encoding`头的请求。
+- 攻击者发送一个带有混淆 `Transfer-Encoding` 头的请求。
-- 根据哪个服务器（前端或后端）未能识别模糊处理，可能会利用CL.TE或TE.CL漏洞。
+- 根据哪个服务器（前端或后端）未能识别混淆，可能会利用 CL.TE 或 TE.CL 漏洞。
-- 请求中未处理的部分在其中一个服务器看来成为后续请求的一部分，导致欺骗。
+- 请求中未处理的部分在其中一个服务器看来成为后续请求的一部分，导致走私。
 - **示例：**
 
 ```
@@ -132,7 +132,7 @@ Transfer-Encoding
 #### **CL.CL 场景（前端和后端都使用 Content-Length）**
 
 - 两个服务器仅根据 `Content-Length` 头处理请求。
-- 此场景通常不会导致欺骗，因为两个服务器在解释请求长度时是一致的。
+- 这种情况通常不会导致走私，因为两个服务器在解释请求长度时是一致的。
 - **示例：**
 
 ```
@@ -146,8 +146,8 @@ Normal Request
 
 #### **CL.0 场景**
 
-- 指的是`Content-Length`头存在且值不为零，表示请求主体有内容。后端忽略`Content-Length`头（被视为0），但前端解析它。
+- 指的是 `Content-Length` 头存在且值不为零，表明请求主体有内容。后端忽略 `Content-Length` 头（被视为0），但前端解析它。
-- 这在理解和构造欺骗攻击中至关重要，因为它影响服务器确定请求结束的方式。
+- 这在理解和构造走私攻击中至关重要，因为它影响服务器确定请求结束的方式。
 - **示例：**
 
 ```
@@ -162,7 +162,7 @@ Non-Empty Body
 #### TE.0 场景
 
 - 类似于前一个场景，但使用 TE。
-- 技术[在此报告](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)。
+- 技术 [在这里报告](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **示例**:
 ```
 OPTIONS / HTTP/1.1
@@ -183,7 +183,7 @@ EMPTY_LINE_HERE
 ```
 #### 破坏网络服务器
 
-此技术在可以**在读取初始HTTP数据时破坏网络服务器**但**不关闭连接**的场景中也很有用。这样，HTTP请求的**主体**将被视为**下一个HTTP请求**。
+该技术在可以**在读取初始HTTP数据时破坏网络服务器**但**不关闭连接**的场景中也很有用。这样，HTTP请求的**主体**将被视为**下一个HTTP请求**。
 
 例如，如[**这篇文章**](https://mizu.re/post/twisty-python)中所述，在Werkzeug中可以发送一些**Unicode**字符，这会导致服务器**崩溃**。然而，如果HTTP连接是使用**`Connection: keep-alive`**头创建的，请求的主体将不会被读取，连接仍将保持打开状态，因此请求的**主体**将被视为**下一个HTTP请求**。
 
@@ -201,7 +201,7 @@ Connection: Content-Length
 
 ## 查找 HTTP 请求走私
 
-识别 HTTP 请求走私漏洞通常可以通过时间技术实现，这依赖于观察服务器对被操控请求的响应时间。这些技术特别适用于检测 CL.TE 和 TE.CL 漏洞。除了这些方法，还有其他策略和工具可以用来发现此类漏洞：
+识别 HTTP 请求走私漏洞通常可以通过时间技术实现，这依赖于观察服务器响应被操纵请求所需的时间。这些技术特别适用于检测 CL.TE 和 TE.CL 漏洞。除了这些方法，还有其他策略和工具可以用来发现此类漏洞：
 
 ### 使用时间技术查找 CL.TE 漏洞
 
@@ -271,7 +271,7 @@ X
 
 在通过干扰其他请求测试请求走私漏洞时，请记住：
 
-- **独立的网络连接：** “攻击”和“正常”请求应通过独立的网络连接发送。对两个请求使用相同的连接并不能验证漏洞的存在。
+- **独立的网络连接：** “攻击”和“正常”请求应通过独立的网络连接发送。对同一连接使用两者不会验证漏洞的存在。
 - **一致的 URL 和参数：** 力求对两个请求使用相同的 URL 和参数名称。现代应用程序通常根据 URL 和参数将请求路由到特定的后端服务器。匹配这些可以增加两个请求由同一服务器处理的可能性，这是成功攻击的前提。
 - **时间和竞争条件：** “正常”请求旨在检测“攻击”请求的干扰，与其他并发应用请求竞争。因此，在“攻击”请求后立即发送“正常”请求。繁忙的应用程序可能需要多次尝试以确认漏洞。
 - **负载均衡挑战：** 作为负载均衡器的前端服务器可能会将请求分配到不同的后端系统。如果“攻击”和“正常”请求最终落在不同的系统上，攻击将不会成功。这个负载均衡方面可能需要多次尝试以确认漏洞。
@@ -355,9 +355,9 @@ X: Y
 - 主机头滥用：结合主机路由怪癖转向内部虚拟主机。
 - 操作员工作流
 - 使用受控重用重现（Turbo Intruder `requestsPerConnection=2`，或 Burp Repeater 标签组 → "按顺序发送组（单个连接）"）。
-- 然后链到缓存/头部泄露/控制绕过原语并演示跨用户或授权影响。
+- 然后链接到缓存/头部泄露/控制绕过原语，并演示跨用户或授权影响。
 
-> 另请参见连接状态攻击，这些攻击密切相关但不属于技术走私：
+> 另请参见连接状态攻击，这与走私密切相关，但在技术上不是走私：
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
@@ -370,7 +370,7 @@ X: Y
 有关背景和端到端工作流：
 
 {{#ref}}
--browser-http-request-smuggling.md
+browser-http-request-smuggling.md
 {{#endref}}
 
 ### 帮助决策的工具
@@ -389,7 +389,7 @@ X: Y
 
 有时，前端代理会实施安全措施，审查传入请求。然而，通过利用 HTTP 请求走私，这些措施可以被规避，从而允许未经授权访问受限端点。例如，访问 `/admin` 可能在外部被禁止，前端代理积极阻止此类尝试。然而，该代理可能未能检查走私 HTTP 请求中的嵌入请求，从而留下绕过这些限制的漏洞。
 
-考虑以下示例，说明如何使用 HTTP 请求走私绕过前端安全控制，特别针对通常由前端代理保护的 `/admin` 路径：
+考虑以下示例，说明如何使用 HTTP 请求走私绕过前端安全控制，特别是针对通常由前端代理保护的 `/admin` 路径：
 
 **CL.TE 示例**
 ```
@@ -426,11 +426,11 @@ a=x
 0
 
 ```
-相反，在TE.CL攻击中，初始的`POST`请求使用`Transfer-Encoding: chunked`，而后续嵌入的请求则基于`Content-Length`头进行处理。与CL.TE攻击类似，前端代理忽视了被隐藏的`GET /admin`请求，意外地授予了对受限`/admin`路径的访问。
+相反，在TE.CL攻击中，初始的`POST`请求使用`Transfer-Encoding: chunked`，而后续嵌入的请求则基于`Content-Length`头进行处理。与CL.TE攻击类似，前端代理忽视了被隐匿的`GET /admin`请求，意外地授予了对受限`/admin`路径的访问。
 
 ### 揭示前端请求重写 <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-应用程序通常使用**前端服务器**来修改传入请求，然后将其传递给后端服务器。典型的修改涉及添加头信息，例如`X-Forwarded-For: <IP of the client>`，以将客户端的IP转发给后端。理解这些修改可能至关重要，因为它可能揭示**绕过保护**或**发现隐藏的信息或端点**的方法。
+应用程序通常使用**前端服务器**来修改传入请求，然后将其传递给后端服务器。典型的修改涉及添加头部，例如`X-Forwarded-For: <IP of the client>`，以将客户端的IP转发给后端。理解这些修改可能至关重要，因为它可能揭示**绕过保护**或**发现隐藏的信息或端点**的方法。
 
 要调查代理如何更改请求，找到一个后端在响应中回显的POST参数。然后，构造一个请求，使用这个参数作为最后一个，类似于以下内容：
 ```
@@ -461,7 +461,7 @@ search=
 
 通过在 POST 操作期间将特定请求附加为参数的值，可以捕获下一个用户的请求。以下是如何实现这一点的： 
 
-通过将以下请求附加为参数的值，可以存储后续客户端的请求：
+通过将以下请求附加为参数的值，您可以存储后续客户端的请求：
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -485,14 +485,14 @@ csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40ema
 
 然而，这种技术有其局限性。通常，它仅捕获 smuggled 请求中使用的参数分隔符之前的数据。对于 URL 编码的表单提交，这个分隔符是 `&` 字符。这意味着从受害者用户请求中捕获的内容将在第一个 `&` 处停止，这可能甚至是查询字符串的一部分。
 
-此外，值得注意的是，这种方法在 TE.CL 漏洞中也是可行的。在这种情况下，请求应以 `search=\r\n0` 结束。无论换行符如何，值将附加到搜索参数中。
+此外，值得注意的是，这种方法在 TE.CL 漏洞中也是可行的。在这种情况下，请求应以 `search=\r\n0` 结束。无论换行符如何，值将被附加到搜索参数中。
 
 ### 使用 HTTP 请求走私来利用反射型 XSS
 
 HTTP 请求走私可以被用来利用易受 **反射型 XSS** 攻击的网页，提供显著的优势：
 
 - **不需要**与目标用户互动。
-- 允许在 **通常无法获取** 的请求部分中利用 XSS，例如 HTTP 请求头。
+- 允许在 **通常无法达到** 的请求部分中利用 XSS，例如 HTTP 请求头。
 
 在网站通过 User-Agent 头易受反射型 XSS 攻击的情况下，以下有效载荷演示了如何利用此漏洞：
 ```
@@ -515,11 +515,11 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-此有效载荷的结构旨在利用该漏洞，具体步骤如下：
+此有效载荷的结构旨在利用该漏洞：
 
 1. 发起一个看似典型的 `POST` 请求，带有 `Transfer-Encoding: chunked` 头以指示走私的开始。
 2. 随后跟随一个 `0`，标记块消息体的结束。
-3. 然后，引入一个走私的 `GET` 请求，其中 `User-Agent` 头被注入一个脚本 `<script>alert(1)</script>`，当服务器处理此后续请求时触发 XSS。
+3. 然后，引入一个走私的 `GET` 请求，其中 `User-Agent` 头被注入一个脚本，`<script>alert(1)</script>`，当服务器处理此后续请求时触发 XSS。
 
 通过走私操控 `User-Agent`，该有效载荷绕过了正常请求约束，从而以非标准但有效的方式利用了反射型 XSS 漏洞。
 
@@ -528,7 +528,7 @@ A=
 > [!CAUTION]
 > 如果用户内容在响应中以 **`Content-type`** 反射，例如 **`text/plain`**，将阻止 XSS 的执行。如果服务器支持 **HTTP/0.9，可能可以绕过这一点**！
 
-HTTP/0.9 版本早于 1.0，仅使用 **GET** 动词，并且 **不** 响应 **头部**，只有主体。
+版本 HTTP/0.9 是在 1.0 之前，仅使用 **GET** 动词，并且 **不** 响应 **头部**，只有主体。
 
 在 [**这篇文章**](https://mizu.re/post/twisty-python) 中，利用了请求走私和一个 **会回复用户输入的易受攻击端点** 来走私一个 HTTP/0.9 请求。响应中反射的参数包含一个 **伪造的 HTTP/1.1 响应（带有头部和主体）**，因此响应将包含有效的可执行 JS 代码，`Content-Type` 为 `text/html`。
 
@@ -570,17 +570,17 @@ Host: vulnerable-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-在这种情况下，用户对 JavaScript 文件的请求被劫持。攻击者可以通过响应恶意 JavaScript 来潜在地危害用户。
+在这种情况下，用户对 JavaScript 文件的请求被劫持。攻击者可以通过响应中提供恶意 JavaScript 来潜在地危害用户。
 
 ### 通过 HTTP 请求走私利用 Web 缓存中毒 <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
 如果 **前端基础设施的任何组件缓存内容**，通常是为了提高性能，则可以执行 Web 缓存中毒。通过操纵服务器的响应，可以 **毒化缓存**。
 
-之前，我们观察到如何改变服务器响应以返回 404 错误（参见 [Basic Examples](#basic-examples)）。同样，可以欺骗服务器以响应对 `/static/include.js` 的请求而提供 `/index.html` 内容。因此，缓存中的 `/static/include.js` 内容被替换为 `/index.html` 的内容，使得用户无法访问 `/static/include.js`，这可能导致服务拒绝（DoS）。
+之前，我们观察到如何改变服务器响应以返回 404 错误（参见 [Basic Examples](#basic-examples)）。同样，可以欺骗服务器以响应对 `/static/include.js` 的请求而提供 `/index.html` 内容。因此，`/static/include.js` 的内容在缓存中被替换为 `/index.html` 的内容，使得 `/static/include.js` 对用户不可访问，可能导致服务拒绝（DoS）。
 
 如果发现 **开放重定向漏洞** 或者存在 **指向开放重定向的站内重定向**，这种技术变得特别强大。这些漏洞可以被利用来将 `/static/include.js` 的缓存内容替换为攻击者控制的脚本，从而实质上使所有请求更新的 `/static/include.js` 的客户端面临广泛的跨站脚本（XSS）攻击。
 
-下面是利用 **缓存中毒结合站内重定向到开放重定向** 的示例。目标是更改 `/static/include.js` 的缓存内容，以提供由攻击者控制的 JavaScript 代码：
+下面是利用 **缓存中毒结合站内重定向到开放重定向** 的示例。目标是改变 `/static/include.js` 的缓存内容，以提供由攻击者控制的 JavaScript 代码：
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -600,7 +600,7 @@ x=1
 ```
 注意嵌入的请求目标是 `/post/next?postId=3`。该请求将被重定向到 `/post?postId=4`，利用 **Host header value** 来确定域名。通过更改 **Host header**，攻击者可以将请求重定向到他们的域名 (**on-site redirect to open redirect**)。
 
-在成功的 **socket poisoning** 之后，应发起对 `/static/include.js` 的 **GET request**。该请求将受到先前 **on-site redirect to open redirect** 请求的污染，并获取由攻击者控制的脚本内容。
+在成功进行 **socket poisoning** 后，应发起对 `/static/include.js` 的 **GET request**。该请求将受到先前 **on-site redirect to open redirect** 请求的污染，并获取由攻击者控制的脚本内容。
 
 随后，任何对 `/static/include.js` 的请求将提供攻击者脚本的缓存内容，有效地发起广泛的 XSS 攻击。
 
@@ -643,13 +643,13 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-一个滥用这种行为的例子是**首先伪装一个HEAD请求**。该请求将仅以GET请求的**头部**进行响应（**`Content-Type`**在其中）。然后立即伪装**一个TRACE请求**，该请求将**反射发送的数据**。\
+一个滥用这种行为的例子是**首先伪装一个HEAD请求**。该请求将仅以GET请求的**头部**进行响应（其中包括**`Content-Type`**）。然后立即伪装**一个TRACE请求**，该请求将**反射发送的数据**。\
-由于HEAD响应将包含一个`Content-Length`头部，**TRACE请求的响应将被视为HEAD响应的主体，因此在响应中反射任意数据**。\
+由于HEAD响应将包含一个`Content-Length`头，**TRACE请求的响应将被视为HEAD响应的主体，因此在响应中反射任意数据**。\
 该响应将被发送到连接上的下一个请求，因此这可以**用于缓存的JS文件中，例如注入任意JS代码**。
 
 ### 通过HTTP响应拆分滥用TRACE <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-继续关注[**这篇文章**](https://portswigger.net/research/trace-desync-attack)建议另一种滥用TRACE方法的方式。如评论所述，伪装一个HEAD请求和一个TRACE请求可以**控制HEAD请求响应中的一些反射数据**。HEAD请求主体的长度基本上在Content-Length头部中指示，并由TRACE请求的响应形成。
+继续关注[**这篇文章**](https://portswigger.net/research/trace-desync-attack)建议另一种滥用TRACE方法的方式。如评论所述，伪装一个HEAD请求和一个TRACE请求可以**控制HEAD请求响应中的一些反射数据**。HEAD请求主体的长度基本上在Content-Length头中指示，并由TRACE请求的响应形成。
 
 因此，新的想法是，知道这个Content-Length和TRACE响应中给出的数据，可以使TRACE响应在Content-Length的最后一个字节之后包含一个有效的HTTP响应，从而允许攻击者完全控制下一个响应的请求（这可以用于执行缓存中毒）。 
 
@@ -672,7 +672,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-将生成这些响应（注意HEAD响应具有Content-Length，使得TRACE响应成为HEAD主体的一部分，一旦HEAD Content-Length结束，就会走私一个有效的HTTP响应）：
+将生成这些响应（注意HEAD响应具有Content-Length，使得TRACE响应成为HEAD主体的一部分，一旦HEAD Content-Length结束，一个有效的HTTP响应被走私）：
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -811,7 +811,7 @@ table.add(req)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
-- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): 该工具是基于语法的 HTTP Fuzzer，有助于发现奇怪的请求走私差异。
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): 该工具是一个基于语法的 HTTP Fuzzer，有助于发现奇怪的请求走私差异。
 
 ## 参考