这道题目算是给了SQL注入另外的思路了。一般而言我们测试SQL注入会选择那些有直接显示的地方（比如id=1，name=xxx），但这会局限你的思维，所以一定要多多培养做题的思路才能应对各种情况。下面会给出不一样的思路：
1.这是墨者学院一道有waf的sql注入，有很多人遇到有waf的环境就感觉头大，确实绕waf很头疼，但waf也有强弱之分，我们要做的就是测试一下对方服务器的waf做了什么，根据waf的特点来绕过它。
2.从下图我们知道，该waf是检测输入的参数值是否存在一些进行SQL注入的字符，如果有就弹出警告并记录在服务器中。
3.因此我们没有必要死磕在怎么绕过waf的上面了，可以换个思路。它不是会把我输入的字符存在服务器上某个文件下嘛（一般是日志文件），那我构造一句话木马传过去不是正好？
这里提个题外话，下面这个是通过F12开发者模式查看器得到的“源码”。
而通过查看网页源代码得到下面的结果。可以发现两者并不一致，下面的才是真正的经过服务器端处理后传给浏览器的源码，而上面的是在浏览器处渲染后的结果。
4.这时把我的一句话木马传过去后发现caidao并不能连接（也有可能能连接，毕竟这是一个公开的靶场，可以把pass换成有独特性的字符。还可能是因为之前可能连接过一次，把cookie存下来了，可以通过清空一下caidao的缓存），如果出现了这种情况，那么这就牵扯到URL编码问题了（这里的sqlin.asp是通过目录扫描得到的）
5.具体的可以上网去搜索一下，这里推荐https://www.cnblogs.com/jerrysion/p/5522673.html
下述图中，%20=空格，%3C=<，%22="，这些全是经过浏览器URL编码的。而经过和原始数据对比发现，一句话木马中的%并没有被URL编码，而当这个未被编码的%传过去后，会被服务器端当做是编码后的数据，服务器会去查看%后面的字符，而后面接的是字母，所以%会被丢弃掉，从而变成<eval request...>,从而不能被执行，导致caidao连接失败。
5.因此，如果想要正确的传入，需要把%编码成%25传过去，就能连接了。
之后就可以去caidao连接了。
6.总结：
1.首先是SQL注入思路的拓展，不仅可以通过上述技巧，而且还可以测试cookie注入，referer注入，http header注入等，一切有可能和数据库产生交互的地方。2.其次是URL编码问题，对于那些有歧义的字符需要编码才能被正确地传给服务器。3.caidao的使用技巧，如果caidao连接失败可以尝试清除缓存。
