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

代码应该始终使用SQL的参数绑定

数据来自何处并不重要；跳过它可能导致二阶SQL注入，或者出现"我忘记更新代码"的情况。只需始终使用SQL参数即可。

只有的一般例外是当无法做到这一点时，例如当需要更改查询本身中的非数据时（例如表名）-在这种情况下，有其他技术可以减轻SQL注入。

虽然参数绑定是一个重要的基石，但"还不够"。

根据定义，正确使用查询参数可以防止所有"经典"SQL注入，但不能保证查询是安全的。

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，而不会更改查询形状。因此，应该始终使用，否则代码将自身设置为失败。

我意识到"总是"answers"只有"是绝对的极端，但我还没有在通用代码中找到违反这些规则的例子。如果底层驱动程序使用内部转义或真正的参数化查询，这也无关紧要——关键是使用参数（除了使查询更干净之外）以一致和可靠的方式消除这一责任。