https://github.com/smxiazi/xia_sql
先推崇一下这个burp插件，其思路和我手工探测SQL注入的原理非常一致。在这个遍地是waf，动不动封你ip的情况下，利用传统爬虫或者sqlmap，那些复杂且特征明显的SQL注入语句只有死路一条。于是原作者简单的在每个参数上加了点料就能轻松识别出SQL注入。
原理是利用了正常，报错，返回为空或者其他结果的返回包大小不一样，以下几种结果大家体会一下。
无SQL注入
有SQL注入且为数字型
有SQL注入且为字符型
其中id=1”的结果很有趣，实际上的SQL语句为where id=’1”’，一共4个单引号，但第2个把第3个转义了，所以实际上是1’，又因为弱类型原因，所以和id=1一样。
无SQL注入
有SQL注入
理清这些逻辑就能利用简简单单waf大概率不会拦截的%2B1和单引号来试探出绝大部分SQL注入了。
通常来说，waf不会拦截参数上的单引号，即使拦截，对于D盾等waf来说，也可以用长参数绕过。可以说这个插件稍微改改就非常通用了。
不过还有改进空间，以下举例。
1，报错也返回为空。
在一些靶场中见过，没有报错提示，只能盲注的情况。
那么显然这种情况单引号就分辨不出来了，反倒是传统的and 1=1可以分辨。
最后几种情况也是很有意思的弱类型。
顺便一提，如果在报错也返回为空的基础上，再加上一个表中无数据。那么就彻底无法构造布尔条件了，只能进行时间盲注探测。
2，参数会反射在返回页面中
这会导致返回包每次都不一样，当然差别仅仅只有几个字节，这种情况可以在返回包中将反射参数替换为原来的。
并且还需要根据XSS不同的防御方式，要将不同的情况都给替换掉。
比如admin’可能反射成以下几种
admin%27admin'admin'admin'admin'admin‘
甚至经历多次编码。
3，有随机因素导致每次返回包大小差几个字节
最典型的是时间戳，特别是header中的，这种情况可只取body长度，以及允许一两个字节的误差。
4，其他数据库
对于access/mssql的字符型注入。
对于oracle的字符型注入。
那么相信大家已经会自己写一个高效的SQL注入插件了吧。
原文始发于微信公众号（珂技知识分享）：高效的黑盒探测SQL注入
