他们是否比做类似的事情更不容易受到 SQL 注入的影响mysql_query("SELECT important_data FROM users WHERE password = $password")？
问问题
5459 次
5 回答
5
它们比您所做的更安全。您的查询将原始 SQL 发布到数据库，这意味着您的参数不被视为 sql 参数，而是被视为普通的旧 sql。
这就是我的意思。
对于存储过程，密码变量不能是 sql，它必须是系统正在寻找的一条信息。在您的示例中，实际发送到数据库的是
SELECT * FROM User where password = ('your password here'--$Password variable).....所以有人可以做类似的事情
SELECT * FROM user WHERE Password = ('your password here';SELECT * FROM User --$password 变量)。
或更糟糕的是：
SELECT * FROM user WHERE Password = ('your password here';DROP Database Database_Name --$password 变量)。
非动态 sql 存储过程不允许这样做，因为输入参数不会作为额外的 sql 执行。
参数化 SQL 确实解决了这个问题，但从技术上讲，存储过程仍然更安全一些，因为访问表中信息的用户不需要读取访问权限。它只需要能够执行存储过程。根据您的需要，这可能会或可能不会发挥作用。
于 2009-06-21T14:50:53.887 回答
4
不一定，您可以在其中进行字符串连接，并且曝光是相同的。如果您使用带有参数变量的动态 sql（没有字符串连接来生成 SQL），您将受到很好的保护。
于 2009-06-21T14:52:52.543 回答
2
只要您使用参数并且不对用户输入的值使用字符串连接，就不会有 SQL 注入的风险。存储过程在这方面有点“安全”，因为它们鼓励您使用参数。但是如果在程序中你做了类似的事情
EXECUTE 'SELECT important_data FROM users WHERE password = ' + @password
然后你将回到第 1 格，并且非常容易受到 SQL 注入的攻击。
此外，还有“准备语句”之类的东西，它们不是存储过程，但也可以使用参数。因此，它们也可用于避免 SQL 注入。
于 2009-06-21T14:55:16.750 回答
0
没有安全的技术。技术只能以安全或不安全的方式使用。
也就是说，存储过程需要更多创造性的编码来允许 SQL 注入——尽管如此，这种情况还是会发生。在我知道的任何 SQL 数据库引擎中，没有什么能阻止您在其中连接字符串。
于 2009-06-21T14:52:24.993 回答
0
如果它们被正确参数化并且您没有执行动态 sql，那么它们会更安全，并且您还将受益于执行计划重用
于 2009-06-21T14:55:12.927 回答