如果我没记错的话，我认为 Jeff 在 Stack Overflow 播客中提到了 SQL 准备语句中可能存在的弱点。我想知道他指的是哪种弱点？可能只是使用不当，还是更险恶？
在我的记忆中，播客并没有深入探讨这个主题，只是顺便说一句。
Henrik Paul
问问题
12136 次
4 回答
6
我认为他说的是，当您使用 Prepared Statements 时，SQL Server 可以缓存您的查询执行计划，因此，即使您修改执行查询的某些参数，服务器也可能选择错误的（可能是缓存的）执行计划那会表现得很糟糕。
他还提到了 SQL Server 2008 的一项新功能，即强制引擎重新评估他用来克服这种情况的执行计划。
使用Prepared Statements，我唯一的问题就是这个。考虑以下 Java 代码：
String sql = "select * from table where name like ?";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setString(1, "PATTERN%");
ResultSet rs = pstmt.executeQuery();
在这里，您会期望，如果您在 table(name) 上有一个索引，它将被查询计划使用。好吧，它不会。因为 PraparedStatement 必须预编译并预期最坏的情况：例如，'%PATTERN%'。所以，它不会优化。我花了一段时间才弄清楚这一点。它导致我的数据库受到影响。:(
希望能帮助到你。
于 2009-03-24T17:37:48.437 回答
2
除了正常的 sql 注入（我们可以称之为一阶）攻击之外，还有二级攻击。例如，存储过程使用字符串连接来构建查询然后执行的情况并不少见。如果检索到的字段值的结果包含在这样的连接中，则存在注入的危险。
于 2009-03-24T17:36:37.097 回答
1
如果准备好的语句具有以任何方式动态构造的参数，那么这很可能是弱点的根源。
如果您使用带有经过测试的类的适当数据库库来设置参数，那么您在任何时候都不会打开自己的 SQL 注入，无论是否准备好语句。
请记住，仅仅因为准备了一条语句，或者因为您正在使用存储过程，这并不意味着您可以免受注入攻击。只有当您使用数据库提供程序代码来清理参数的输入（以及将其应用于所有可以使用的参数）时，您才能获得 SQL 注入保护。
于 2009-03-24T17:36:13.213 回答
0
我没有听过播客，但根据我的经验，只有准备好的陈述才是好的。它通常可以提高应用程序的性能并防止 SQL 注入（如果使用得当，而不是作为链接中的第二个示例）。
于 2009-03-24T17:35:10.500 回答