|
锁定老帖子 主题：SQL注入攻击防御方案
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-03-21
这位大哥 写了 fastjson 又弄了个sql注入防御的，真是牛人啊~~ 中国软件事业就靠你啦~ 不过还是花时间多陪陪家人比较好~~
|
| 返回顶楼 | |
|
发表时间：2012-03-21
yuechen323 写道 这位大哥 写了 fastjson 又弄了个sql注入防御的，真是牛人啊~~ 中国软件事业就靠你啦~ 不过还是花时间多陪陪家人比较好~~
太高的帽子不敢带。。。 这是捧杀吧 |
| 返回顶楼 | |
|
发表时间：2012-03-21
每次看到项目组里的人写“脏脏”的代码就会很蛋疼....
|
| 返回顶楼 | |
|
发表时间：2012-03-21
wenshao 写道 yuechen323 写道 这位大哥 写了 fastjson 又弄了个sql注入防御的，真是牛人啊~~ 中国软件事业就靠你啦~ 不过还是花时间多陪陪家人比较好~~
太高的帽子不敢带。。。 这是捧杀吧 哈哈哈，阿里人表示有压力（俺不是阿里 也不是淘宝系的） |
| 返回顶楼 | |
|
发表时间：2012-03-21
最后修改：2012-03-21
youarestupid 写道 wenshao 写道 项目中的人员素质不一，人员多，代码越多，越容易出问题，只要有一个遗漏，就悲剧了。
入侵者从此获得用户密码，拖库。。。 重大风险面前，低成本在连接池上引入拦截，性价比还是很高的！ 如果Druid不存在SQL注入风险，那么它肯定会对所有需要执行的SQL语句，都进行执行前过滤处理，这样的话，如果我需要像我上面举例的需求：需要动态修改字段结构、动态创建子表、动态更改字段类型等，Druid如何来做到？ 新增加了doPrivileged的功能，测试场景看这里： https://github.com/AlibabaTech/druid/blob/master/src/test/java/com/alibaba/druid/bvt/filter/wall/DoPrivilegedTest.java // 被拦截
Assert.assertFalse(WallUtils.isValidateMySql("select @@version_compile_os"));
// 不被拦截
WallProvider.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
Assert.assertTrue(WallUtils.isValidateMySql("select @@version_compile_os"));
return null;
}
});
|
| 返回顶楼 | |
|
发表时间：2012-03-21
在看代码，又没注释，如果能补充点class diagram多好啊。。文档最好也补充点吧
|
| 返回顶楼 | |
|
发表时间：2012-03-21
wenshao 写道 youarestupid 写道 wenshao 写道 项目中的人员素质不一，人员多，代码越多，越容易出问题，只要有一个遗漏，就悲剧了。
入侵者从此获得用户密码，拖库。。。 重大风险面前，低成本在连接池上引入拦截，性价比还是很高的！ 如果Druid不存在SQL注入风险，那么它肯定会对所有需要执行的SQL语句，都进行执行前过滤处理，这样的话，如果我需要像我上面举例的需求：需要动态修改字段结构、动态创建子表、动态更改字段类型等，Druid如何来做到？ 新增加了doPrivileged的功能，测试场景看这里： https://github.com/AlibabaTech/druid/blob/master/src/test/java/com/alibaba/druid/bvt/filter/wall/DoPrivilegedTest.java // 被拦截
Assert.assertFalse(WallUtils.isValidateMySql("select @@version_compile_os"));
// 不被拦截
WallProvider.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
Assert.assertTrue(WallUtils.isValidateMySql("select @@version_compile_os"));
return null;
}
});对于确实十分敏感，但是又不得不执行通过页面输入值组装而成的原生SQL的场景，可以加入人工审核过程，比如： 如果需要管理员，在后台中动态创建表结构，可以在接收到页面传递过来的表名称、字段结构等数值后，组装成完整的SQL语句，但是不立刻执行这个SQL语句，而是把这个SQL语句的字符串，转换成16进制字符串，插入数据库，然后程序进入超级管理员审核阶段，超级管理员通过一个单独的程序（和生成SQL语句的程序完全无关），得知有一个需要他审核的SQL语句，然后超级管理员从数据库中取得这个16进制的SQL语句，还原成普通SQL字符串，人工查看SQL语句是否存在注入漏洞，如果不存在注入漏洞，超级管理员就放行这条SQL语句，此时工作流返回到普通管理员的界面上，普通管理员此时再执行人工审核通过的SQL语句。 这种处理，理论上可以最大化地防止SQL注入，如果这样还防不住SQL注入，那么只能怪超级管理员审核SQL语句时太粗心。 这种折腾法，只针对一些“不紧迫”的场景，比如，假设淘宝网允许店长自定义商品属性，自定义的商品属性就是动态创建的一个子表（当然，这种需求实际上不必创建子表，可以用通用纵表来解决），这种需求下，淘宝网的超级管理员可以对店长提交过来的建表SQL语句进行人工审核。 如果需求要求立刻执行原生SQL语句，不容许翻来覆去地人工审核SQL，那么上面这种折腾法就不适用了。 |
| 返回顶楼 | |
|
发表时间：2012-03-21
刚刚去viki看了下，还不错，想得防御都很详细全面。
|
| 返回顶楼 | |
|
发表时间：2012-03-21
flashing 写道 如果你用的是prepared，这玩意有啥用吗。。。这是给asp和php用的把，汗
话说php也可以用prepare，这是数据库提供的支持。如果数据库支持prepare，这个东西还有用吗？ |
| 返回顶楼 | |
|
发表时间：2012-03-21
surfire91 写道 flashing 写道 如果你用的是prepared，这玩意有啥用吗。。。这是给asp和php用的把，汗
话说php也可以用prepare，这是数据库提供的支持。如果数据库支持prepare，这个东西还有用吗？ 对啊，大家怎么老说php存在注入漏洞，java不存在。。。我看不是一样的嘛。。。 |
| 返回顶楼 | |
