关于防止sql注入的几种手段(一)

关于防止sql注入的几种手段(一),第1张

其实特别不愿意说sql注入的问题,因为这的确是个老掉牙的问题了,但是仍然还有不少人在这方面自以为安全性做得很到位,或者说万事只要存储过程就可以防止注入,即全都参数化,这样对于某些复杂逻辑来说,sql存储过程写法太过于冗长,不如在C#拼凑sql,也有很多人鄙视拼凑sql的人,我觉得,看待sql注入这个问题,应该是从本质上来杜绝注入,而不是想当然的依靠存储过程,拒绝拼凑sql。我说一下我自己的经验吧一 存储过程参数化能解决绝大部分的注入问题。存储过程之所以能够解决绝大部分的注入问题,是因为mssql的机制,它认为你的是参数就是参数不能够解析为可执行的sql。但是这仅仅能解决绝大部分问题二 当需要在proc里面动态拼凑sql,使用类似exec,sp_executesql的时候,一定要使用后者,虽然两者都是传递一个字符串,这个字符串作为sql语句执行,但是后者提供为sql语句提供参数的功能,使得被执行的sql语句参数化,而防止注入,前者如果使用传入的参数来拼凑sql,则参数就会间接转换成sql语句而导致注入。本想接着写, 临时有点事,晚上发第二篇

SQL注入并不是一个在SQL内不可解决的问题,这种攻击方式的存在也不能完全归咎于SQL这种语言,因为注入的问题而放弃SQL这种方式也是因噎废食。首先先说一个我在其他回答中也曾提到过的观点:没有(运行时)编译,就没有注入。
SQL注入产生的原因,和栈溢出、XSS等很多其他的攻击方法类似,就是未经检查或者未经充分检查的用户输入数据,意外变成了代码被执行。针对于SQL注入,则是用户提交的数据,被数据库系统编译而产生了开发者预期之外的动作。也就是,SQL注入是用户输入的数据,在拼接SQL语句的过程中,超越了数据本身,成为了SQL语句查询逻辑的一部分,然后这样被拼接出来的SQL语句被数据库执行,产生了开发者预期之外的动作。
所以从根本上防止上述类型攻击的手段,还是避免数据变成代码被执行,时刻分清代码和数据的界限。而具体到SQL注入来说,被执行的恶意代码是通过数据库的SQL解释引擎编译得到的,所以只要避免用户输入的数据被数据库系统编译就可以了。
现在的数据库系统都提供SQL语句的预编译(prepare)和查询参数绑定功能,在SQL语句中放置占位符'',然后将带有占位符的SQL语句传给数据库编译,执行的时候才将用户输入的数据作为执行的参数传给用户。这样的 *** 作不仅使得SQL语句在书写的时候不再需要拼接,看起来也更直接,而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行,也不会越权变成代码。
至于为什么这种参数化的查询方式没有作为默认的使用方式,我想除了兼容老系统以外,直接使用SQL确实方便并且也有确定的使用场合。

1、对,限制用户输入肯定有效
2、应该也可以做到,但正则不是一种高效的方法,用HtmlEncode的方法可以有效防止空格等被DBMS解释,但注意别把编码、解码搞反了;存储过程是DBMS执行的一段程序,把数据 *** 纵交给存储过程执行,而不是提交SQL语句,可以有效防止SQL注入。
3、地址栏的Sql攻击,下面我引用了一段资料解释,他关于机制说的较清楚,关于解决,只是从客户端考虑的,实际上用存储过程等都可以防范。
资料:
首先,入侵者会对一个网站确定可不可以进行注入,假设一篇文章的地址为:>参数化sql语句
请采纳!
具体原因,请采纳以下信息:
针对于SQL注入,则是用户提交的数据,被数据库系统编译而产生了开发者预期之外的动作。也就是,SQL注入是用户输入的数据,在拼接SQL语句的过程中,超越了数据本身,成为了SQL语句查询逻辑的一部分,然后这样被拼接出来的SQL语句被数据库执行,产生了开发者预期之外的动作。
所以从根本上防止上述类型攻击的手段,还是避免数据变成代码被执行,时刻分清代码和数据的界限。而具体到SQL注入来说,被执行的恶意代码是通过数据库的SQL解释引擎编译得到的,所以只要避免用户输入的数据被数据库系统编译就可以了。
现在的数据库系统都提供SQL语句的预编译(prepare)和查询参数绑定功能,在SQL语句中放置占位符'',然后将带有占位符的SQL语句传给数据库编译,执行的时候才将用户输入的数据作为执行的参数传给用户。这样的 *** 作不仅使得SQL语句在书写的时候不再需要拼接,看起来也更直接,而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行,也不会越权变成代码。
至于为什么这种参数化的查询方式没有作为默认的使用方式,我想除了兼容老系统以外,直接使用SQL确实方便并且也有确定的使用场合。
多说一点,从代码的角度来看,拼接SQL语句的做法也是不恰当的。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/13412094.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-07-31
下一篇 2023-07-31

发表评论

登录后才能评论

评论列表(0条)

保存