---

当你的才华

还撑不起你的野心时

那你就应该静下心来学习

---

目录

HTTP请求走私漏洞 [基于CL.TE利用]

0x01 前言

0x02 什么是HTTP请求走私？

0x03 HTTP请求走私漏洞产生的原因？

0x04 走私攻击实现方法？

0x05 HTTP请求走私的五种方式

1）CL不为0

2）CL-CL

3）CL-TE

4）TE-CL

5）TE-TE

0x06 漏洞环境准备

0x07 漏洞复现

---

 

HTTP请求走私漏洞 [基于CL.TE利用]

0x01 前言

为什么会出现多次请求

这与最为广泛的HTTP 1.1的协议特性——Keep-Alive&Pipeline有关。

在HTTP1.0之前的协议设计中，客户端每进行一次HTTP请求，需要同服务器建立一个TCP链接。

而现代的Web页面是由多种资源组成的，要获取一个网页的内容，不仅要请求HTML文档，还有JS、CSS、图片等各种资源，如果按照之前的协议设计，就会导致HTTP服务器的负载开销增大。于是在HTTP1.1中，增加了Keep-Alive和Pipeline这两个特性。

Keep-Alive：在HTTP请求中增加一个特殊的请求头Connection: Keep-Alive，告诉服务器，接收完这次HTTP请求后，不要关闭TCP链接，后面对相同目标服务器的HTTP请求，重用这一个TCP链接。这样只需要进行一次TCP握手的过程，可以减少服务器的开销，节约资源，还能加快访问速度。这个特性在HTTP1.1中默认开启的。

Pipeline(http管线化)：http管线化是一项实现了多个http请求但不需要等待响应就能够写进同一个socket的技术，仅有http1.1规范支持http管线化。在这里，客户端可以像流水线一样发送自己的HTTP请求，而不需要等待服务器的响应，服务器那边接收到请求后，需要遵循先入先出机制，将请求和响应严格对应起来，再将响应发送给客户端。

现在，浏览器默认不启用Pipeline的，但是一般的服务器都提供了对Pipleline的支持。

下面这是典型的CDN加速图和拓扑结构图

CDN加速图

拓扑结构图

 

0x02 什么是HTTP请求走私？

      HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

 

0x03 HTTP请求走私漏洞产生的原因？

      该漏洞产生原因主要是前后端服务器对请求处理RFC标准不同。造成后端恶意代码缓存驻留

RFC2616规范

      如果接收的消息同时包含传输编码头字段(Transfer-Encoding)和内容长度头(Content-Length)字段，则必须忽略后者。

      由于规范默许可以使用Transfer-Encoding和Content-Length处理请求，因此很少有服务器拒绝此类请求。每当我们找到一种方法，将Transfer-Encoding隐藏在服务端的一个chain中时，它将会回退到使用Content-Length去发送请求。

      HTTP请求走私漏洞时利用了解析了两个HTTP设备（通常时前端服务器(CDN)和后端服务器，接收数据不同步，引起对客户端传入的数据理解不一致，从而导致漏洞）

      HTTP请求走私是通过发送多个特制HTTP请求来执行的，这些请求导致两个被攻击实体看到两组不同的请求

可以这么理解：

      大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求的结束位置：Content-Length标头和Transfer-Encoding标头。

      同时使用两种不同的方法时，Content-Length无效。当使用多个服务器时，对客户端传入的数据理解不一致时，就会出现有些服务器认为Content-Length的长度有效，有些以Transfer-Encoding有效。而一般情况下，反向代理服务器与后端的源站服务器之间，会重用TCP链接。这样超出的长度就会拼接到下一次请求进行请求，从而导致HTTP请求走私漏洞。

上面的不太理解的话，我们可以这么理解：

      HTTP请求走私攻击涉及将Content-Length标头和Transfer-Encoding标头都放置在单个HTTP请求中并进行处理，以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为：

CL.TE：前端服务器使用Content-Length标头，而后端服务器使用Transfer-Encoding标头。

TE.CL：前端服务器使用Transfer-Encoding标头，而后端服务器使用Content-Length标头。

TE.TE：前端服务器和后端服务器都支持Transfer-Encoding标头，但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。

 

0x04 走私攻击实现方法？

      当向代理服务器发送一个比较模糊的HTTP请求时，由于两者服务器的实现方式不同，代理服务器可能认为这是一个HTTP请求，然后将其转发给了后端的源站服务器，但源站服务器经过解析处理后，只认为其中的一部分为正常请求，剩下的那一部分，就算是走私的请求，当该部分对正常用户的请求造成了影响之后，就实现了HTTP走私攻击。

      自从HTTP1.1 keepalive协议以来，服务器在基于流的传输层协议（例如TCP/IP协议）上说HTTP或TLS，为了方便提高性能，这些流被大量重用，意味着请求是背靠放置在这些流上，链中的每个服务器都是，通过两个不同的http标头来计算每个消息的持续时间，但是这一段传输过程途中，从两个不同的HTTP头开始输出—>停止（汇总多个不同用户的TCP/TLS到一条单通道的链路上）—>到达路由后，重新从数据流停止处开始（但多个不同的TCP/TLS 在停止时，将两者放到同一个单链路上时，他们如果校验不严格，可能会出错）

      此时，假设蓝色（黑客）发送一个带有恶意攻击的Payload（橙色）代码，正常的是蓝色+橙色，前端服务器会认为蓝色和橙色数据块是一个请求，此时夹杂在正常（蓝色）数据中的橙色（恶意Payload代码）会被前端随着正常的数据块整合到一起立即发送出去，留到后端服务器，但由于种种原因，后端认为这消息是以第二个蓝色板块（橙色恶意代码）结尾，因此认为橙色橙色数据是下一个请求的开始，它只是在等待，在该请求完成之前要完成第二个请求，并且怎么样才能很好的完成该请求，可以有效处理走私请求，我们可以申请别人的请求的任意前缀。    

      但是,这个攻击过程，我们无法通过前端直接看到反馈，因为是发生在后端服务器的，很容易让人搞混，我们可以使用一个简单的方法来，验证（漏洞复现过程中会说）。     

      如果你收到包含内容的信息，则并进行分块，你应该优先考虑这些分块，然后将其隐寓的说，这些信息很好，你不应该拒接他们，只需要将它们标准化，只需以这种方式处理它们，一切都会好起来的，但事实是，如果你的链接中有一台服务器违反了该规则，优先考虑了内容的长度，那一切都不会好。

 

0x05 HTTP请求走私的五种方式

1）CL不为0

      所有不携带请求体的HTTP请求都有可能受此影响。这里用GET请求举例。

      前端代理服务器允许GET请求携带请求体；后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。

\r\n是换行的意思，windows的换行是\r\n，unix的是\n，mac的是\r

攻击流程：

      前端服务器收到该请求，读取Content-Length，判断这是一个完整的请求。

      然后转发给后端服务器，后端服务器收到后，因为它不对Content-Length进行处理，由于Pipeline的存在，后端服务器就认为这是收到了两个请求，就造成了漏洞的发生，分别是：

第一个：

GET / HTTP/1.1\r\nHost: test.com\r\n

第二个：

GET / secret HTTP/1.1\r\nHost: test.com\r\n

2）CL-CL

RFC7230规范

      在RFC7230的第3.3.3节中的第四条中，规定当服务器收到的请求中包含两个Content-Length，而且两者的值不同时，需要返回400错误。

      有些服务器不会严格的实现该规范，假设中间的代理服务器和后端的源站服务器在收到类似的请求时，都不会返回400错误。

      但是中间代理服务器按照第一个Content-Length的值对请求进行处理，而后端源站服务器按照第二个Content-Length的值进行处理。

构造请求示例：

POST / HTTP/1.1\r\nHost: test.com\r\nContent-Length: 8\r\nContent-Length: 7\r\n12345\r\n
a

攻击流程：

      中间代理服务器获取到的数据包的长度为8，将上述整个数据包原封不动的转发给后端的源站服务器。

      而后端服务器获取到的数据包长度为7。当读取完前7个字符后，后端服务器认为已经读取完毕，然后生成对应的响应，发送出去。而此时的缓冲区去还剩余一个字母a，对于后端服务器来说，这个a是下一个请求的一部分，但是还没有传输完毕。

      如果此时有一个其他的正常用户对服务器进行了请求：

GET /index.html HTTP/1.1\r\nHost: test.com\r\n

      因为代理服务器与源站服务器之间一般会重用TCP连接。所以正常用户的请求就拼接到了字母a的后面，当后端服务器接收完毕后，它实际处理的请求其实是：

aGET /index.html HTTP/1.1\r\nHost: test.com\r\n

      这时，用户就会收到一个类似于aGET request method not found的报错。这样就实现了一次HTTP走私攻击，而且还对正常用户的行为造成了影响，而且还可以扩展成类似于CSRF的攻击方式。

      但是一般的服务器都不会接受这种存在两个请求头的请求包。该怎么办呢？

      所以想到前面所说的

RFC2616规范

      如果收到同时存在Content-Length和Transfer-Encoding这两个请求头的请求包时，在处理的时候必须忽略Content-Length。

      所以请求包中同时包含这两个请求头并不算违规，服务器也不需要返回400错误。导致服务器在这里的实现更容易出问题。

3）CL-TE

      CL-TE，就是当收到存在两个请求头的请求包时，前端代理服务器只处理Content-Length请求头，而后端服务器会遵守RFC2616的规定，忽略掉Content-Length，处理Transfer-Encoding请求头。

chunk传输数据(size的值由16进制表示)

[chunk size][\r\n][chunk data][\r\n][chunk size][\r\n][chunk data][\r\n][chunk size = 0][\r\n][\r\n]

chunked 编码

      参考：https://blog.csdn.net/God_XiangYu/article/details/105504781

构造请求示例：

POST / HTTP/1.1\r\n
Host: test.com\r\n
......
Connection: keep-alive\r\n
Content-Length: 6\r\n
Transfer-Encoding: chunked\r\n\r\n
0\r\n
\r\n
a

连续发送几次请求就可以获得响应。

攻击流程：

由于前端服务器处理Content-Length，所以这个请求对于它来说是一个完整的请求，请求体的长度为6，也就是

0\r\n
\r\n

0\r\n
\r\n
a

当请求包经过代理服务器转发给后端服务器时，后端服务器处理Transfer-Encoding，当它读取到

0\r\n
\r\n

认为已经读取到结尾了。

但剩下的字母a就被留在了缓冲区中，等待下一次请求。当我们重复发送请求后，发送的请求在后端服务器拼接成了类似下面这种请求：

aPOST / HTTP/1.1\r\nHost: test.com\r\n

......

服务器在解析时就会产生报错了，从而造成HTTP请求走私。

4）TE-CL

      TE-CL，就是当收到存在两个请求头的请求包时，前端代理服务器处理Transfer-Encoding请求头，后端服务器处理Content-Length请求头。

构造请求示例：

POST / HTTP/1.1\r\nHost: test.com\r\n......Content-Length: 4\r\nTransfer-Encoding: chunked\r\n\r\n
12\r\naPOST / HTTP/1.1\r\n\r\n
0\r\n
\r\n

攻击流程：

前端服务器处理Transfer-Encoding，当其读取到

0\r\n
\r\n

认为是读取完毕了。

此时这个请求对代理服务器来说是一个完整的请求，然后转发给后端服务器，后端服务器处理Content-Length请求头，因为请求体的长度为4.也就是当它读取完

12\r\n

就认为这个请求已经结束了。后面的数据就认为是另一个请求：

aPOST / HTTP/1.1\r\n\r\n
0\r\n
\r\n

成功报错，造成HTTP请求走私。

 

5）TE-TE

      TE-TE，当收到存在两个请求头的请求包时，前后端服务器都处理Transfer-Encoding请求头，确实是实现了RFC的标准。不过前后端服务器不是同一种。这就有了一种方法，我们可以对发送的请求包中的Transfer-Encoding进行某种混淆操作(如某个字符改变大小写)，从而使其中一个服务器不处理Transfer-Encoding请求头。在某种意义上这还是CL-TE或者TE-CL。

构造请求示例：

POST / HTTP/1.1\r\nHost: test.com\r\n......Content-length: 4\r\nTransfer-Encoding: chunked\r\nTransfer-encoding: cow\r\n\r\n5c\r\naPOST / HTTP/1.1\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 15\r\n\r\nx=1\r\n0\r\n\r\n

攻击流程：

前端服务器处理Transfer-Encoding，当其读取到

0\r\n
\r\n

认为是读取结束。

此时这个请求对代理服务器来说是一个完整的请求，然后转发给后端服务器处理Transfer-encoding请求头，将Transfer-Encoding隐藏在服务端的一个chain中时，它将会回退到使用Content-Length去发送请求。读取到

5c\r\n

认为是读取完毕了。后面的数据就认为是另一个请求：

aPOST / HTTP/1.1\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 15\r\n\r\n
x=1\r\n
0\r\n
\r\n

成功报错，造成HTTP请求走私。

 

0x06 漏洞环境准备

这里已CL.TE来做演示，利用的是PORTSWIGGER 实验室在线靶场做环境

https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te

这里首先需要去注册，如果已经注册的话，就无需去注册了，登陆即可

创建邮箱

 

成功发送邮件

打开邮件，点击Click here 链接完成注册

重新点击登陆，输入刚刚注册的账号

登陆后，转至Web安全学院

往下拉，一直找到HTTP请求走私的那一栏

 

0x07 漏洞复现

      有时候我们通过Burp Suite 代理浏览Web网页时，在被动（主动）扫描的仪表盘选项卡中标记了HTTP请求走私，如果缺乏理解，很有可能会忽略掉该漏洞，以为是误报。

      有时此漏洞可能很难被利用，因为我们自己不太理解该漏洞，我们先用BurpSuite 被动扫描一下，再去仪表盘看看有啥漏洞

正在扫描

      当发送具有格式错误的内容长度和传输编码头的请求时，Burp会将其标记为HTTP请求走私漏洞。当其中一个响应超时，Burp将它标记为HTTP请求走私漏洞。

 

那么我们该如何校验是否是误报呢？

开启实验

【HTTP请求走私 基于CL.TE漏洞】

      CL-TE，就是当收到存在两个请求头的请求包时，前端代理服务器只处理Content-Length请求头，而后端服务器会遵守RFC2616的规定，忽略掉Content-Length，处理Transfer-Encoding请求头。

      在这里，前端服务器使用Content-Length头，而后端服务器使用Transfer-Encoding头

开启BurpSuite后，设置浏览器代理抓包，并刷新当前页面

抓包发送repeater模块及注意事项：

需要转换一下格式：

修改包并发送正常请求：Send 一下，此时参数A留在了缓存，第一次发包返回正常内容

重放一次刚刚的包，回显我们的缓存数据Agan，告诉我们没有这个APOST

可以从一张图中，更清晰的理解

      前端服务器处理Content-Length标头，并确定请求正文的长度为6个字节，直到结尾的A，该请求被转发到后端服务器。

      后端服务器处理Transfer-Encoding标头，因此将消息正文视为使用分块编码。它处理第一个块，该块被声明为零长度，因此被视为终止请求。接下来的字节A保留未处理，后端服务器会将其视为序列中下一个请求的开始。

 

其它几个实例... ...，后面再慢慢写... 累了累了

参考链接:

               https://www.idc4.com/news_view.asp?ID=116&RID=

               https://paper.seebug.org/1048/

               https://xz.aliyun.com/t/6654

---

虽然我们生活在阴沟里，但依然有人仰望星空！

---