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%27
admin'
admin'
admin'
admin\'
admin‘
甚至经历多次编码。 3,有随机因素导致每次返回包大小差几个字节
最典型的是时间戳,特别是header中的,这种情况可只取body长度,以及允许一两个字节的误差。 4,其他数据库 对于access/mssql的字符型注入。
对于oracle的字符型注入。
那么相信大家已经会自己写一个高效的SQL注入插件了吧。