Question

我需要说服某人除了存储过程的用户之外他还需要清理用户输入。嗯，我知道我听起来很疯狂，但我对商店程序感到不舒服。我的第一个原因是我能够在存储过程中导致错误，但由于应用程序本身处理错误以便错误消息被编码，因此外部很难理解存在的错误。但我仍然认为这不安全。

有人有建议吗？或者我错误地怀疑存储过程？

Answer 1

不，它本身并不安全。您还可以在存储过程中执行以下操作：

SET @sql = 'Select * from products where name like ''' +@spinput+''' ';
exec(@sql);

@spinput中的值错误，您可以注入代码。

但是，您可以编写对sql注入安全的存储过程。

Answer 2

即使您使用适当的参数，您仍然可以使用数据库。您可以插入一个作为参数输入的脚本，但是当它在网页上显示时，它会开始做一些它不应该做的事情。使用参数确保数据库按预期使用，但也可以在以后清理输出 - 永远不要信任用户输入的数据。

Answer 3

使用存储过程通常可以防止SQL注入，但不是防止SQL注入的唯一解决方案，并且它不能防止所有形式的SQL注入。

这不是存储过程本身产生重大差异，而是参数化查询，这是调用存储过程的最常用方法。通过将查询使用的值放在参数中，您可以让数据库库处理它们，而不必自己正确地转义它们。

可以在不使用参数化查询的情况下编写对SQL注入安全的代码，但这很困难。你必须准确地知道你需要在字符串中为你正在使用的特定数据库转义哪些字符，如果你弄错了，你几乎就像你根本不了解SQL注入一样没有保护。

如果使用参数化查询，那么将值发送到数据库的步骤对于SQL注入是安全的，但查询本身可能不是。如果查询生成并执行SQL代码本身，则正确转义字符串时会遇到同样的问题。然而，在SQL代码中创建SQL代码并不常见，如果你这样做，你就会意识到你正在这样做。