关于SQL防注入

Question

如果我把客户端传递过来的string参数所有的\r和\n都替换成--并在string的最前头加上--下面语句还能被注入么?如果有人说能的话, 就给出代码来.
//大家可以把字符串123替换成任意字符串 尝试一下sql拼接语句是否能够执行成功(顶多执行失败)
string content = "123".Replace("\r", "--").Replace("\n", "--").Replace("'", "--").Insert(0, "--");
string password = "123".Replace("\r", "--").Replace("\n", "--").Replace("'", "--").Insert(0, "--");
string sql = "insert into [News] values( '" + title + "','" + content + "')";
string content = "123".Replace("\r", "--&nb^rfvd@34d##22f4#3n6b%38fn").Replace("\n", "--&nb^dwfd@934##034ea#3n3d%cc4n").Replace("'", "--&nb^&#39@64a##f23d#3n48%e4an").Insert(0, "--&nb^thdw@689##86d3#3n2f%aa2n");
//取数据时 content = "123".Replace("--&nb^rfvd@34d##22f4#3n6b%38fn", "\r").Replace("--&nb^dwfd@934##034ea#3n3d%cc4n", "\n").Replace("&nb^&#39@64a##f23d#3n48%e4an", "'").Replace("--&nb^thdw@689##86d3#3n2f%aa2n", "");
"123".Replace("<", "&lt;");//防止客户端javascript脚本注入

Answer 1

在数据库安全方面注意点
对于数据库操作的 sql语句 注意点 如截长判断

Answer 2

参数化
http://topic.csdn.net/u/20090729/14/26381958-0d6e-4b90-bc90-d275e9621f93.html

Answer 3

sjzlxd  为什么要替换成--???
--在SQL Server中是注释的意思  如果你这么替换  会出错的吧
假如SQL语句
select * from table where a = '123/r';
被你这么一替换  
select * from table where a = '123--';
后面一个单引号就被注释掉的  SQL语句也就不成立  会出错的哦一般都是将危险字符给过滤掉  就是替换成空

Answer 4

人生如梦大哥 是为了推荐使用.net自带的参数化类  自定将有危险的字符给过滤掉了  不用我们这么辛苦一个一个去研究哪些是可疑的字符 然后再去过滤
当然了  有些字符根据项目要求还是需要的  这个时候就必须自己来处理了  就不能用参数化了  

Answer 5

谁说参数化就可以防止注入了? 参数化 或者使用存储过程 也都有可能. 不过 漏洞都是程序员自己弄出来的.要从根源上解决注入. 就要考虑sql语句根源处理方式.

Answer 6

拼接的sql 谁敢说这辈子不用?但是万一要用了怎么办? 肯定要解决注入.其实简单写个方法.插入或者更新的时候直接替换.查询出来以后再替换回去.此办法存在以下问题:1.损耗了一定的性能(任何防止注入的方法都不可避免)2.万一原数据中就存在替换以后的字符串 则替换回来之后 跟原来的字符串不同了之前使用过的方法,是把要插入的结果进行转换编码. 取的时候再转回来.效率也不错.但是依然存在2个问题1.损耗一定性能2.万一入侵者知道了你的编码方式, 比如知道服务器每次都将utf-8转化为ascii
则侵入者将准备执行的ascii编码语句,然后用utf-8转码 最后进行注入
到服务器以后 服务器使用了utf-8转ascii 转化回来,变成可执行sql语句... 后果...

Answer 7

我给你出个主意，你把客户端传来的string的内容全都删除，只剩下sp1234，这肯定防注入了！客户端整个系统都不能录入本该可以录入的东西（比如一个单引号），就别奢谈什么防注入了。

Answer 8

你还是留下hhc123意思是事不过3