最后更新于
最后更新于
当前端代理和后端服务器之间发生不同步时，会出现此漏洞，使得攻击者能够发送一个 HTTP 请求，该请求将被前端代理（负载均衡/反向代理）解释为单个请求，而被后端服务器解释为2个请求。 这使得用户能够在其之后到达后端服务器的下一个请求中修改请求。
如果接收到的消息同时具有传输编码头字段和内容长度头字段，则必须忽略后者。
Content-Length
Content-Length 实体头指示发送给接收方的实体主体的字节数。
Transfer-Encoding: chunked
Transfer-Encoding 头指定用于安全传输有效载荷主体的编码形式。 Chunked 意味着大数据以一系列块的形式发送
前端（负载均衡 / 反向代理）处理 content-length 或 transfer-encoding 头，而后端服务器处理另一个头，导致这两个系统之间的不同步。 这可能非常危险，因为攻击者将能够向反向代理发送一个请求，该请求将被后端服务器解释为2个不同的请求。这种技术的危险在于后端服务器将会将注入的第二个请求解释为来自下一个客户端，而该客户端的真实请求将成为注入请求的一部分。
请记住，在 HTTP 中，一个换行符由 2 个字节组成：
Content-Length：此头使用十进制数来指示请求主体的字节数。预期请求主体在最后一个字符结束，请求的末尾不需要换行符。
Transfer-Encoding: 此头在主体中使用十六进制数来指示下一个块的字节数。块必须以换行符结尾，但是长度指示符不计算这个换行符。此传输方法必须以大小为 0 的块后跟 2 个换行符结束：0
Connection：根据我的经验，建议在请求串行的第一个请求中使用**Connection: keep-alive**。
尝试使用 Burp Suite 利用此漏洞时，在重复器中禁用 Update Content-Length 和 Normalize HTTP/1 line endings，因为一些小工具会滥用换行符、回车和格式不正确的 content-length。
HTTP 请求串行攻击是通过发送模棱两可的请求来制造的，利用前端和后端服务器解释 Content-Length（CL）和 Transfer-Encoding（TE）头的差异。这些攻击可以以不同形式出现，主要是CL.TE、TE.CL 和 TE.TE。每种类型代表前端和后端服务器如何优先处理这些头的独特组合。漏洞源于服务器以不同方式处理相同请求，导致意外且可能恶意的结果。
前端（CL）： 根据 Content-Length 头处理请求。
后端（TE）： 根据 Transfer-Encoding 头处理请求。
攻击场景：
攻击者发送一个请求，其中 Content-Length 头的值与实际内容长度不匹配。
前端服务器根据 Content-Length 值将整个请求转发给后端。
后端服务器由于 Transfer-Encoding: chunked 头而将请求处理为分块，将剩余数据解释为单独的、随后的请求。
示例：
前端（TE）： 根据 Transfer-Encoding 头处理请求。
后端（CL）： 根据 Content-Length 头处理请求。
攻击场景：
攻击者发送一个分块请求，其中块大小（7b）和实际内容长度（Content-Length: 4）不对齐。
前端服务器遵循 Transfer-Encoding，将整个请求转发给后端。
后端服务器遵循 Content-Length，仅处理请求的初始部分（7b 字节），将其余部分作为意外的随后请求的一部分。
示例：
服务器： 两者都支持Transfer-Encoding，但可以通过混淆来欺骗其中一个。
攻击场景：
攻击者发送带有混淆的Transfer-Encoding头的请求。
取决于哪个服务器（前端或后端）无法识别混淆，可能会利用CL.TE或TE.CL漏洞。
请求的未处理部分，由其中一个服务器看到，将成为后续请求的一部分，导致走私。
示例：
两个服务器仅基于Content-Length头处理请求。
这种情况通常不会导致走私，因为两个服务器在解释请求长度方面是一致的。
示例：