分析源码
GET/POST/REQUEST/COOKIE都会经过这个替换str_ace(array('&', '"', '<', '>','(',')'), array('&', '"', '<', '>','（','）'), $string)
GET/POST/REQUEST三个变量，都会经过这个正则：select\|insert\|update\|delete\|'\|/\*\|\*\|\.\./\|\./\|union\|into\|load\_file\|outfile
一旦遇到select，包括单引号，包括注释符，就立即exit整个流程
这个过程等于手工处理了一遍REQUEST\_URI，将REQUEST\_URI中的字符串分割成数组覆盖到REQUEST里。
按道理来说并没有什么大错误，但试想：这个过程是在我们的第一道WAF之后进行的，假设我们有一个方法让第一道WAF认为请求中没有恶意字符，再通过这里的覆盖，将恶意字符引入$_REQUEST中，就可以造成WAF的绕过了。
所以怎么样才能让第一个waf认为我们的请求没有恶意字符呢？
php的特性
php中他会取最后一个值
假设我有一个办法，在第一次WAF检测参数的时候，检测的是2，但后面覆盖request的时候，拿到的是1，那么不就可以造成WAF的绕过了么？
虽然没有报错，但这里我们两个传参都是用的i_d，最终我们进入到查询语句中的时候他还是只会取第二个值
所以这里并没有意义
php另外一个特性
php另一个特性，自身在解析请求的时候，如果参数名字中包含” “、”.”、”[“这几个字符，会将他们转换成下划线。
那如果我发送的是这样一个请求： php?i_d=11111&i.d=22222 ，php先将i.d转换成i_d，即为php?i_d=11111&i_d=22222 ，再获取到的$\_REQUEST i_d就是22222。
可在$\_SERVER\['REQUEST\_URI'\]中，i_d和i.d却是两个完全不同的参数名，那么切割覆盖后，获取的$\_REQUEST\['i_d\]却是11111。
实现注入
联合查询注入
发现我们其实是可以绕过的
爆库
用limit观察
爆表名
爆列名
爆出flag
