请求走私漏洞
前言
前两天外出去打了数字中国数据安全赛道的线下赛，题目挺有意思的，学到不少新东西。请求走私漏洞便是其中之一。这个点应该是决赛上午共同防御的的一道题目，整体的思路听上去分享情报的师傅说是先用工具打shiro框架，生成payload后用请求走私绕过后台WAF的长度限制。当时看了先知集的几个文档但是没看太懂，打完来补一补。
基本介绍
简单看了下这个漏洞，说白了就是前后端对于请求包的边界不一致，攻击者若发送一个模棱两可的攻击语句就可能会在前后端分别产生不同的结果。
如今的 Web 应用程序经常在用户和最终应用程序逻辑之间使用 HTTP 服务器链。用户将请求发送到前端服务器（有时称为负载平衡器或反向代理），然后该服务器将请求转发到一个或多个后端服务器。这种类型的架构在现代基于云的应用程序中越来越常见，在某些情况下是不可避免的。
当前端服务器将 HTTP 请求转发到后端服务器时，它通常会通过同一个后端网络连接发送多个请求，因为这样效率更高、性能更高。协议非常简单；HTTP 请求一个接一个地发送，接收服务器必须确定一个请求在哪里结束，下一个请求在哪里开始。
攻击类型
- CL.TE
- TE.CL
- TE.TE
实验环境： bp实验室 /i/l/?n=23&i=blog/3035827/202405/3035827-20240526225130122-605772801.png 先找到发送POST请求包的接口  抓包，请求包如下：  发送到Repeater,相应配置下：
1、取消Update CL
2、修改请求属性中的HTTP协议版本为1
 修改POST请求包发送内容，添加Transfer-Encoding请求头
发包两次即可  Transfer-Encoding处的chunked用于指定该消息体正文包含一个或多个数据块，该消息以大小为0的块终止，例如上图中的
0
G
则是后端认为请求在“0”处已终止，于是成功将G进行走私