使用preparedStatement是否意味着不会有任何SQL注入？
我读过，为了防止 SQL 注入，必须使用PreparedStatement。
这是否意味着如果我使用 perparedStatement 那么没有人可以在我的任何页面中执行 SQL 注入？它能万无一失地抵御 SQL 注入吗？如果没有，请举一些例子来证明这一点。
I have read that to prevent SQL Injection one must use PreparedStatement.
Does that mean if i am using perparedStatement then no one can perform SQL Injection in any of my page? Is it foolproof against SQL Injection? If not then please give some example to demonstrate this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尽管预准备语句有助于防御 SQL 注入，但仍存在通过不当使用预准备语句而遭受 SQL 注入攻击的可能性。
下面的示例解释了这样一种场景，其中输入变量直接传递到准备好的语句中，从而为 SQL 注入攻击铺平了道路。
如果处理不当，准备好的语句可能容易受到 SQL 注入的攻击。</strong>
Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements.
The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks.
prepared statement can be vulnerable to SQL injection if it is not done properly.
简短的回答：是的，如果使用得当的话。
然而，这并不意味着 JDBC 驱动程序中不会存在可用于 SQL 注入的错误。当我为我工作的公司调查这个问题时，我发现我们使用的 JDBC 驱动程序之一（PostgreSQL）确实存在 SQL 注入错误。这是几年前的事了，这个错误已经修复了。
虽然我不记得具体细节，但我记得查看过 JDBC 实现的源代码，发现它是通过字符串连接实现的。
不过，我预计这种情况很少见，我的建议是相信实现并正确使用PreparedStatements。
Short answer: yes, if used properly.
However, this does not mean that there can't be bugs in the JDBC driver, opening up for SQL injection. When I looked into this for a company I worked at, I found that there was indeed an SQL injection bug in one of the JDBC drivers we used (PostgreSQL). This is some years ago, and the bug was fixed.
Although I don't remember the specifics, I recall looking at the source code for a JDBC implementation, and seeing that it was implemented with string concatenation.
I would expect this to be rare, though, and my advice would be to trust the implementation and use PreparedStatements properly.
只要您实际上使用准备好的语句的参数替换功能（有可能误用它们而不使用该功能），并且假设您正在使用的准备好的语句库中没有错误，那么您应该可以很好地抵御原始 SQL 注入。但这并不意味着您不应该怀疑用户提供给您的任何内容。 :-)
As long as you're actually using the parameter substitution feature of the prepared statement (it's possible to misuse them and not use that feature), and provided there isn't a bug in the prepared statement library you're using, then you should be fine against raw SQL injection. That doesn't mean you shouldn't treat whatever the user gives you with suspicion, though. :-)
准备好的语句不涵盖查询的非数据部分 - 标识符和运算符。
因此，如果其中一些是可变的并且直接添加到查询中，则注入是可能的。
由于可能的选项数量有限，所有变量标识符都应根据用户输入从预先编写的变体中选择。对于运营商来说也是如此。
不应将用户输入直接添加到查询中。
prepared statements do not cover non-data parts of the query - identifiers and operators.
thus, if some of them are variable and being added to the query directly, injection is possible.
thanks to limited number of possible options, all variable identifiers should be chosen from pre-written variants based on user input. same for operators.
No user input should be added to the query directly.
使用所提供语言的预准备语句功能意味着您正在使用经过尝试和测试的解决方案来解决该问题 - 这并不意味着永远不存在任何错误或 SQL 注入可能性的范围，但它的真正含义是您并不是唯一使用该实现的人。使用相同实现的人越多，意味着发现和消除错误的机会就越多 - 如果您使用自己的实现，那么只有您可以找到并修复错误。
Using the prepared statement feature of the language provided means you are using a tried and tested solution for the problem - it doesn't mean that there are never any bugs or scope for SQL Injection possibilities, but what it does mean is that you are not the only person using the implementation. The more people using the same implementation for something means the more chances for bugs to be found and eliminated - if you use your own implementation then only you can find and fix the bugs.