|
其实特别不愿意说sql注入的问题，因为这的确是个老掉牙的问题了，但是仍然还有不少人在这方面自以为安全性做得很到位，或者说万事只要存储过程就可以防止注入，即全都参数化，这样对于某些复杂逻辑来说，sql存储过程写法太过于冗长，不如在C#拼凑sql，也有很多人鄙视拼凑sql的人，我觉得，看待sql注入这个问题，应该是从本质上来杜绝注入，而不是想当然的依靠存储过程，拒绝拼凑sql。我说一下我自己的经验吧
一 存储过程参数化能解决绝大部分的注入问题。存储过程之所以能够解决绝大部分的注入问题，是因为mssql的机制，它认为你的是参数就是参数不能够解析为可执行的sql。但是这仅仅能解决绝大部分问题 二 当需要在proc里面动态拼凑sql，使用类似exec，sp_executesql的时候，一定要使用后者，虽然两者都是传递一个字符串，这个字符串作为sql语句执行，但是后者提供为sql语句提供参数的功能，使得被执行的sql语句参数化，而防止注入，前者如果使用传入的参数来拼凑sql，则参数就会间接转换成sql语句而导致注入。 第二条或许应该再补充一下，在mysql里，也有类似的执行动态语句的，就是PREPARE+execute，这个的使用和mssql里的sp_executesql功效相同，也能够带参数，防止动态sql语句注入。 sql语句如下： 这个是转自邹健大哥的，邹健想必大家都认识，让我们来试一下他的通用存储过程：
exec sp_PageView 'article','articleid',1,10,'subject,articleid',' articleid desc;select 1 as ''ok''; ','', null
看看返回什么吧：
注入成功！ 那这个到底怎么回事呢？？？ 邹健大哥的通用存储过程都存在漏洞吗？
到底什么样的写法才不会被注入呢？太恐怖了 |
相关文章：