防止sql注入性攻击

1、关于防止sql注入的几种手段 其实特别不愿意说sql注入的问题，因为这的确是 个老掉牙的问题了，但是仍然还有不少人在这方面自以为安全性做得很到位，或者说万事只 要存储过程就可以防止注入，即全都参数化，这样对于某些复杂逻辑来说，sql存储过程写法太过于冗长，不如在 C#拼凑sql，也有很多人鄙视拼凑 sql的人，我觉得，看待 sql注入这 个问题，应该是从本质上来杜绝注入，而不是想当然的依靠存储过程，拒绝拼凑sql。我说一下我自己的经验吧一存储过程参数化能解决绝大部分的注入问题。存储过程之所以能够解决绝大部分的注入问题，是因为mssql的机制，它认为你的是参数就是参数不能够解析为可执行的sql。

2、但是这仅仅能解决绝大部分问题二当需要在proc里面动态拼凑 sql，使用类似 exec，sp_executesql的时候，一定要使用后者，虽然两者都是传递一个字符串，这个字符串作为sql语句执行，但是后者提供为sql语句提供参数的功能，使得被执行的sql语句参数化，而防止注入，前者如果使用传入的参数来拼凑sql，则参数就会间接转换成sql语句而导致注入。第二条或许应该再补充一下，在mysql里，也有类似的执行动态语句的，就是PREPARE+execute，这个的使用和 mssql里的sp_executesql功效相同，也能够带参数，防 止动态sql语句注入。在很多应用场景里面，用户最烦的就是分

3、页的存储过程写法，所以，很多人就发明了通用的存储过程分页，可以通过site:通用存储过程分页在gg里搜索，居然有32000条收录，先不说别的，看看排名前三位的的吧，1 ngyuli/archive/2009/01/13/1375196.html2 ng/archive/2005/09/02/228573.html3 nt/archive/2007/10/17/927825.html都是有注入漏洞的，随便拿一个来试试注入，排名第一的， sql语句如下：0E Code这个是转自邹健大哥的，邹健想必大家都认识，让我们来试一下他的通用存储过程：exec sp_PageView 'article

4、','articleid',1,10,'subject,articleid',' articleid desc;select 1 as ''ok''',”，null看看返回什么吧:H结果1匕消息1articled1036262_在你没成功前，你一定要坚持1036253今年牛市牛气指数是多少？1036244谧州人敢想，温州人更敢干103E235金融危机为民退国进提供了机遇103622£物流电孑商务凤起云涌.江湖决战近在明年103E211Erw肝厠话耶波帝卡服怖总经理吴诗梅103E18e创业的年龄10

5、36141ii i;注入成功!那这个到底怎么回事呢？ ？邹健大哥的通用存储过程都存在漏洞吗？到底什么样的写法才不会被注入呢？太恐怖了上回说到邹健大哥的存储过程有漏洞，有人又提出这个很多都是程序员加上去的，压根就不可能注入，的确，有很多拼凑sql的时候是程序里面加上去的，不是来自外界的直接”输入。我上次的演示例子是基于的最后的排序，那如果要是在where条件里面呢？能保证100%都不是来自外界的输入吗？另外，软件的分层开发，很多程序员的水平参差不齐， 能保证where条件都能100%保证过滤了外界的邪恶输入吗？还有，能保证过滤 100%能抵 挡黑客的攻击吗？这样，我们再来看看园子里的人是如何防止

6、注入攻击的，在gg搜索框输入：site:防止 sql 注入2750 条记录，第一篇是 文中只讲了原则，没有实施手段。提到的asp .net安全缺陷解决，在客户端使用服务器验证控件验证，这个是绝对不可靠的，客户端验证是为的用户体验，黑客是不会在浏览器框里输 入的。所有的验证都必须要在服务器端再次验证。排名第二位的是 , kill 朋友的，有具体的实施手段，防止sql注入的策略，一眼看去那个过滤，就知道有个地方没有注意到，xp_cmdshell命令没有过滤。肯定是有漏洞，当然你可以保证你的系统里面扩展存 储过程是默认关闭的，但是你不能保证其他阅读了你文章的用户基于某些原因开启了扩展存 储过程。废话

7、一下，强烈建议不要开启扩展存储过程，如果要使用，看clr proc能不能满足你的需求，不过开启clr也是需要数据库付出一定的代价的，数据库不是很繁忙，可以开启。排名第三位的是转载自csdn的， ng/archive/2008/04/26/1172407.html也是基于的过滤。基于过滤的方法不是不行，不是达不到效果，而是基于过滤你不能保证你过滤完所有的 危险，如果你认为你过滤完所有的危险，你觉得用户会很方便吗？就像我现在写的文章一样，如果博客园使用过滤，那我这篇文章能被发表吗？所以基于过滤貌似是行不通的，但是有些 时候如果全都是参数化，存储过程又太过于复杂，那些不经常写存储过程的程序员很是头疼

8、，怎么办呢？总结我自己的开发经验来说，没有任何绝对的，只有结合具体情况具体考虑。1检查，类型检查，如果是 int 定要tryparse,如果是有限的几个值，一定要枚举匹配。如 果是日期一定要转成日期转入数据层。2长度，长度是个非常重要的因素，比如登录，如果用户名是严格限死的10个字符以内就10个字符以内，用户名中间没有空格就检查不能有空格，但是这个长度因素是需要严格控制的，不能把长度放开到10个字符以上，因为"truncate table s"和这个"drop table s",长度需要跟具体需求具体确定，不能全部一刀切。如果有哪位可以在10个字符以内注

9、入成功的，还请告之，我赶紧改我的程序了，呵呵。3过滤检查，如果压根不可能出现xp_的地方一定要过滤，至于其他的， delete,drop，很多地方都不能确保如果前两个检查不能排除危险的话到第三步过滤建议还是都是用存储过程参数化（或语句参 数化），因为到第三步的时候已经不能确保100%防止注入了。还有的时候，经常被群里的人或朋友问到如果我要传递多个ID进去，比如批量删除，有什么办法，网上的解决办法很多，我就不说了，主要有在存储过程里字符串拆分组成临时表，或者使用邹健大哥的使用func,配合apply。这些都很复杂，实现起来需要很强的sql 根底，不过我的实现就是确保提交过的字符串只有数字和半角逗号组成即可。这样就能确保 没有注入可能，然后使用拼凑 sql的方式+语句参数化其他 where条件来确保安全。其实在这几年我自己的开发历程中，我自己总结我自己对sql注入的安全性认识，经历了几个认识阶段和惨痛教训。1最初的不知道什么叫 sql注入2使用过滤危险关键字来防止注入3使用参数化存储过程4有些地方需要使用