分析源码

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