如果我使用存储过程,我是否可以免于SQL注入？

让我们说MySQL数据库(如果重要).

如果您坚持使用参数化查询,则只能免于SQL注入.如果你在任何地方使用适当的转义,你几乎不受SQL注入的影响(但是在逃避例程中可能存在并且一直存在错误,所以它不像参数那样万无一失).

如果你调用存储过程,通过连接添加参数,我仍然可以在其中一个输入字段的末尾添加一个随机查询 - 例如,如果你有CALL CheckLogin @username ='$ username',@ password =' $ password',$ -things表示直接连接的变量,没有什么能阻止我将$ password变量更改为"'; DROP DATABASE; - ".

显然,如果事先清理输入,这也有助于防止SQL注入,但这可能会过滤掉不应该清理的数据.

不,你不会完全安全.正如其他人所提到的,无论你如何访问数据库,参数化查询总是要走的路.

这是一个城市传说,有了触发你是安全的.我认为人们处于这种错觉之中的原因是因为大多数人都认为你将使用代码中的参数化查询调用procs.但是,如果你不这样做,例如你做了类似下面的事情,你就是敞开的:

SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con);
cmd.ExecuteNonQuery();

因为您正在使用最终用户的未经过滤的内容.再次,他们所要做的就是终止线路(";"),添加他们的危险命令,然后繁荣 - 你就被冲洗了.

(顺便说一句,如果你在网络上,不要从浏览器的查询字符串中获取未经过滤的垃圾 - 这使得对你的数据做极其糟糕的事情变得非常容易.)

如果您对查询进行参数化,那么您的形状会更好.但是,正如其他人提到的那样,如果你的proc仍在生成动态SQL并执行它,那么可能仍然存在问题.

我应该注意,我不是反过程.过程对于解决数据访问的某些问题非常有帮助.但是,procs 并不是 SQL注入的"银弹解决方案".

这取决于您的存储过程的作用.如果他们根据参数动态生成SQL,然后执行该SQL,那么您仍然容易受到攻击.否则,你很可能会很好 - 但我毫不犹豫地100%自信!

不.如果您正在构建调用存储过程的SQL,那么您仍然是目标.

您应该在客户端创建参数化查询.