【发布时间】：2014-06-19 07:26:41
【问题描述】：
SQLInjection 攻击解决了“参数化查询”用参数替换外部值的方法。但我不知道它带来的缺点。如果有的话，那将是一个很大的帮助。 :)
【问题讨论】：
【发布时间】：2014-06-19 07:26:41
【问题描述】：
应用我们知道的所有技术来防止注入总是一个好主意。 参数化查询的“优点”主要是避免“OR 1=1”和其他常见的 SQL 注入：您强制数据库将绑定变量中的所有内容解释为数据，而不是 SQL 指令。因此，如果我不怀好意，就很难放弃你的一张桌子。
参数化 SQL 的“缺点”主要与您没有习惯的灵活性有关（您不能同时进行两个查询，有两个 while 循环，第二个使用 or例如，在 MySQLi 中尝试使用第一次调用获得的参数，而不进行一些调整。切换时可能会发现的问题示例如Nested looping with mysqli and fetch_object 或here 所述）。这不是避免切换到更安全的编程的好理由，而且我认为它还可以防止人们可能在所谓的“香草编程”中养成的一些坏习惯（就我而言，我已经获得了一些），但是，作为回答这个问题的其他人指出，也有解决方法。我不知道其他缺点，可能是因为没有。
您也可以参考关于 SO 的相关问题，例如 Are Parameters really enough to prevent Sql injections? 等等。我不确定这不是重复的，但我还是会回复以消除您的疑虑。
【讨论】：
-
确实，参数化查询通常通过准备查询来工作，这有时会导致@tattvamasi 提到的缺点。准备好的查询可能还有其他缺点，例如某些数据库中的服务器端内存开销（最近有一篇关于此的文章）。
-
@YourCommonSense，让我们同意不同意。 :-J 将两个或多个查询组合成一个请求是一种合理的优化（有时称为“流水线”），并非所有 parameterized=prepared 查询实现都能很好地处理它。
-
我已经编辑了答案，因为我的意思可能不清楚。这不是严格意义上的“骗局”。对于那些切换并习惯于进行嵌套调用的人来说，这是一个“骗局”，顺便说一句，据我所知，他们已经有一个危险信号。这个人（从我们假设他是男性的激进回复中）不应该在不知道妄想是什么的情况下说出妄想。在谈论之前必须打开其他类型的书籍。相关领域的研究生学位是必须的。结束无意义的谈话。 @SandeepPareek 我希望这会有所帮助！如果没有，下面还有另一个很好的答案。
-
@tattvamasi，恕我直言，嵌套查询的问题（当它们由 MySQL 驱动程序流式传输时）与参数化/准备的查询无关。
-
@tattvamasi，我想
mysqli在流式传输方面可能是/不一致的，但即便如此，真正的问题是流式传输以及 MySQL 如何实现它，并且可以通过以下方式轻松修复使用非流式版本（例如fetch_all）。归结为这样一个事实，即“缺乏灵活性”和可行的“嵌套查询”是两个不同的缺点，应该在你的答案中相应地分开。只是我的两分钱。
我看到的一个缺点是使查询更难阅读和修改。幸运的是，有解决方法，所以不要写
"SELECT foo + ? FROM bar WHERE x = ? AND y = ? AND z IN (?, ?)", offset, x, y, z1, z2
你可以在 Scala Slick 中编写
sql"SELECT foo + $offset FROM bar WHERE x = $x AND y = $y AND z IN ($z1, $z2)"
在 MySQL++ 中
query << "SELECT foo + " << quote << offset << " FROM bar WHERE x = " << quote << x << " AND y = " << quote << y << " AND z IN (" << quote << z1 << ", " << quote << z2 << ")"
【讨论】：
-
您始终可以使用特定领域的语言进行抽象。
-
使用 DSL，您根本不需要参数化查询。还有ORM。不过，我是 LINQ 的忠实粉丝：我想用我的自然 (Scala/C++) 语言编写查询，并且我希望自动提取我的部分代码，发送到数据库并在那里运行。我们需要像 leaningtech.com/cheerp 和 opalang.org 和 Scala.JS 这样的东西来弥合数据库客户端和数据库服务器之间的差距。