响应拆分EXP编写

响应拆分攻击？别慌！手把手带你从零编写EXP，看完直呼“原来如此”！

哎，兄弟们，今天咱们来聊点硬核的——响应拆分（Response Splitting） 攻击，以及怎么动手编写一个像模像样的EXP，说实话，我第一次接触这个漏洞的时候，心里那叫一个懵圈啊！啥是响应拆分？咋就能把HTTP响应给“掰弯”了？后来自己动手琢磨，又查了一堆资料，才恍然大悟——这玩意儿说白了，就是利用输入点注入CRLF（回车换行），从而篡改服务器返回的数据，甚至能在里面夹带私货（比如伪造页面、植入恶意脚本）。

咱今天不讲那些枯燥的理论，我就以我自己的学习路径，跟你唠唠怎么一步步把一个空白的EXP给“填”出来，你可得准备好小板凳,听我慢慢道来！

第一步：先搞懂“响应拆分”到底是个啥鬼？

你可能会问：“哎，响应拆分和CRLF注入有啥区别？” 嘿，问得好！其实响应拆分是CRLF注入的一种典型攻击场景，你想啊，HTTP协议是用\r\n（回车+换行）来分隔头部和身体（Body）的,如果后端代码不小心把用户的输入直接拼接到了响应头里，

resp.set_header("X-Custom-Header", user_input)

这时候，如果user_input里带上了%0d%0a（URL解码后的\r\n），服务器就会傻乎乎地以为你要结束当前头部，开一个新行，你一开新行，就能伪造任意的响应头了！再配合上Content-Length或者Location，甚至能实现缓存投毒（Cache Poisoning）或者XSS攻击！想想就刺激,是不是？

我当初看到这里，心里那叫一个激动,仿佛打开了新世界的大门。

第二步：编写EXP前的“装备检查”

写EXP，咱得先明确目标，是直接打RCE（远程命令执行），还是只想证明存在注入点？对于响应拆分,咱们的EXP通常有两个目标：

验证漏洞存在：发送一个包含CRLF的请求,看看服务器是不是返回了两个不同的响应块。
构建攻击载荷：注入Content-Length或者Location头，配合\r\n\r\n塞入一段伪造的HTML（比如钓鱼页面）。

咱们的EXP得包含这几个核心模块：

目标URL拼接：这个简单,就是拼字符串。
Payload构造：这是灵魂！得把CRLF转义成实际字符，比如在Python里，payload = "/redirect%0d%0aX-Injected: haha"。
发送请求：可以用Python的socket或者requests库，但请注意，requests库有时候会帮你处理掉URL里的特殊字符，所以为了精准控制，我更喜欢用原始socket，那感觉，就像自己开赛车,想怎么飙怎么飙！

写到这里，我不禁想起当年我调试代码的时候，老不成功，最后发现是编码问题——得,说多了都是泪！

第三步：动手写EXP——我的“纸上谈兵”

来，咱直接上代码思路（伪代码）,展示下核心逻辑：

连接目标主机
构造原始HTTP请求：
    GET /search?q=hello%0d%0aSet-Cookie: admin=true%0d%0a%0d%0a<html>伪造页面</html> HTTP/1.1
    Host: 目标站点
发送请求
接收所有响应数据
检查返回的数据里是否包含了“Set-Cookie: admin=true”
如果包含，恭喜！漏洞存在，EXP成功！

你看，是不是看起来挺简单的？但这里有几个大坑,我当初就踩过：

编码问题：服务器会解码URL编码的%0d%0a，但是你不会直接发送真正的回车符，在socket发送前，要把%0d%0a替换成\r\n。
请求头顺序：有些服务器对请求头顺序敏感，所以要把Content-Length卡在伪造内容之前,不然服务器会等半天。
代理影响：如果你处于代理后面，代理可能会过滤掉恶意请求，这时，你得会设置隧道（CONNECT方法）。

哎呀，聊到踩坑，我又想起那次为什么我的Payload不生效——原来是因为我忘了在Host头后面加\r\n，结果把整个请求体给搞乱了！当时急得我直挠头，后来一查,原来还是基本功不扎实。

第四步：EXP的进阶——从验证到利用

如果你仅仅满足于弹出一个Set-Cookie，那你可就“肤浅”了，真正的实战中，咱们要的是链子（Chain）。

响应拆分 + 缓存投毒：你注入一个Content-Length头，让缓存服务器把两个不同的响应块缓存下来，这样，后面访问同一个URL的用户，就会看到你伪造的那个页面啦！这利用思路,简直绝了！
响应拆分 + 会话固定：强制给用户设置一个已知的Session ID，然后等目标用户登录,你就可以冒充他啦！

看吧，响应拆分的EXP写起来，其实是一层窗户纸，捅破了,就能看到背后广阔的攻防天地。