防止注射的参数？够了吗？应该在每个查询中使用它吗？

Question

通过长期的研究，我发现防止注入的参数是一个很好的实践，但是我应该在每个查询中还是仅仅在登录页面中使用它呢？为什么？

非常感谢

Answer 1

代码应该始终使用为SQL.使用参数绑定。

数据来自何处并不重要；跳过这会导致http://en.wikipedia.org/wiki/SQL_injection#Second_Order_SQL_Injection SQL注入，或者出现“我忘记更新代码”的情况。只要一直使用SQL参数即可。

唯一的一般例外是当不能这样做时，例如当需要更改查询本身中的非数据时(例如。(表名)-在这种情况下，还有其他技术可以减轻SQL注入。

虽然是重要的基石，但参数绑定是“不够”的。

根据定义，正确使用查询参数会阻止所有http://en.wikipedia.org/wiki/SQL_injection，但并不保证查询是安全的。

SQL注入是一种代码注入技术，用于攻击数据驱动的应用程序，其中恶意SQL语句被插入到入口字段中执行。

也就是说，虽然以下内容没有SQL注入，因为查询形状无法更改，但仍然不能保证查询是“安全的”或“安全的”。

$name_from_user = $_GET['name'];
prepare('SELECT nuke_code FROM secrets WHERE name = :name');
execute(array('name' => $name_from_user));

这显然是潜在的安全性(fsvo)风险，因为它在查询中使用了未使用/未验证的数据。在这种情况下，只信任来自服务器的数据或在执行查询之前由服务器验证的数据。

此外，SQL注入(因此也包括参数)不涵盖违反业务规则的行为。这些应该与“SQL的清理/验证”分开执行。希望代码使用DAL/BLL，这样逻辑就不会散落在几十个PHP文件中。

在回答基本问题时需要记住的是，使用SQL参数可以确保所提供的数据在不改变查询形状的情况下进入SQL。因此，应该始终使用它们--否则代码本身就会设置为失败。

我意识到“总是”和“只有”是绝对极端的，但我还没有在一般代码中找到这样的例子。如果底层驱动程序使用内部转义或真正的参数化查询，那么它也是无关紧要的--重点是使用参数(除了使查询更清晰)，以一致和可靠的方式消除这一责任。