网络安全-为什么使用ADO能根本杜绝SQL注入?
SQL注入的危害不用我说,由于对URL输入参数过滤不严造成的,为什么使用ADO连接对象能够杜绝呢?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
SQL注入的危害不用我说,由于对URL输入参数过滤不严造成的,为什么使用ADO连接对象能够杜绝呢?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(4)
ADO和PDO、JDBC一样并不提倡你直接用变量值拼接SQL,如下的写法是不被推荐的:
“select * from table where f = ”. $abc
而是提倡另一种写法,写个C#写法:
string strSql = "select * from table where f = @f";
OleDbCommand cmd = new OleDbCommand(strSql,Conn);
cmd.Parameters.Add("@f", OleDbType.VarChar).Value = abc;
所以并不是使用ADO就杜绝了,而是ADO帮你完成SQL的拼接,在处理参数的过程中已经帮你进行了有效的过滤,如果仍然是手写的SQL,即便ADO也不能避免SQL注入
我想先说下SQL注入的原理,我们通过post或者get的方式将一段sql语句字串发送到服务,服务器在接受到字串时,执行本省的SQL查询时,由于没有对浏览器发送过来的字串检查,字串本身也作为参数执行了,导致了恶意的SQL语句执行,通常防止SQL语句注入的方式是,字符串的过虑的方式,但这种方式不能还好的防止注入,ado.net在这方面做了很好的功能,主要是它对post或者get上来的请求和数据,全部参数化处理了,参数化的结果是语句中的单引号等特殊字符都被转义了,同时对参数化的类提供过滤,只对设置的参数通过,不对库构成威胁。
示例:
传统的查询语句的sql可能为
string sql="select * from users where user_id='"+Request.QueryString["uid"]+"'";
很显然,我们在这里拼接了字符串,这就给sql注入留下了可乘之机。
现在,我们要改写这样的语句,使用SqlParameter来做
SqlCommand SqlCmd = new SqlCommand(sql, SqlConn);
SqlParameter _userid = new SqlParameter("uid", SqlDbType.Int);
_userid.Value = Request.QueryString["u_id"];
SqlCmd.Parameters.Add(_userid);
你不能确定所有应用场景中都不允许输入一些跟注入相关的特殊字符,尤其是技术类网站,难道不允许用户贴代码么?最好的方式还是参数化输入。
在web开发应用中,可以从架构层统一处理表单录入信息,进行过滤。之后在应用注重实现。