SQL存储过程是否安全？

Question

它们是否比 mysql_query（＆quot; SELECT important_data FROM users WHERE password = $ password＆quot;）更容易受到SQL注入攻击？

Answer 1

它们比你正在做的更安全。您的查询是将原始SQL发布到db，这意味着您的参数不被视为sql参数，而是作为普通的旧sql。

这就是我的意思。

使用存储的prococedure，密码变量不能是sql，它必须是系统正在寻找的一条信息。在您的示例中，实际发送到数据库的是

SELECT * FROM User where password =（'您的密码在这里' - $密码变量）.....所以有人可以做点什么

SELECT * FROM user WHERE Password =（'您的密码在这里'; SELECT * FROM User - $ password variable）。

或更糟：

SELECT * FROM user WHERE Password =（'your password here'; DROP Database Database_Name - $ password variable。）

非动态sql存储过程不允许这样做，因为输入参数不会作为额外的sql执行。

参数化SQL确实解决了这个问题，但技术上存储的过程仍然更加安全，因为访问表中信息的用户不需要读取访问权限。它只需要能够执行存储过程。根据您的需要，这可能会也可能不会发挥作用。

Answer 2

不一定，你可以在其中进行字符串连接，曝光也是一样的。如果您使用带有参数变量的动态sql（没有字符串连接来生成SQL），那么您将受到相当好的保护。

Answer 3

只要您使用参数并且不对用户输入的值使用字符串连接，就不会有SQL注入的风险。存储过程有点“更安全”。在这方面，因为他们鼓励你使用参数。但是如果在程序中你做了类似的事情

EXECUTE 'SELECT important_data FROM users WHERE password = ' + @password

然后你将回到1号方，非常容易受到SQL注入。

此外，还有“准备好的陈述”之类的内容。这些不是存储过程，但也可以使用参数。因此，它们也可用于避免SQL注入。

Answer 4

没有安全技术。技术只能以安全或不安全的方式使用。

也就是说，存储过程需要稍微更有创意的编码来允许SQL注入 - 但这仍然会发生。在我所知道的任何SQL数据库引擎中，没有什么能阻止你在它们中连接字符串。

Answer 5

如果它们被正确参数化并且您没有使用动态sql，那么它们会更安全，您也将从执行计划重用中受益