这个 MySQL 查询为何容易受到 SQL 注入攻击？

Question

在对上一个问题的评论中，有人说以下 sql 语句让我面临 sql 注入：

select
    ss.*,
    se.name as engine,
    ss.last_run_at + interval ss.refresh_frequency day as next_run_at,
    se.logo_name    
from 
    searches ss join search_engines se on ss.engine_id = se.id
where
    ss.user_id='.$user_id.'
group by ss.id
order by ss.project_id, ss.domain, ss.keywords

假设 $userid 变量已正确转义，这如何使我容易受到攻击，我能做什么做什么来修复它？

Answer 1

每个值得使用的 SQL 接口库都对绑定参数提供某种支持。 不要试图变得聪明，只要利用它即可。

你可能真的、真的认为/希望你已经正确地逃避了一些事情，但不值得花时间。

此外，一些数据库支持预准备语句缓存，因此正确使用也可以为您带来效率提升。

更简单、更安全、更快。

Answer 2

假设它被正确逃脱，它不会让你变得脆弱。 问题是，正确地转义比乍一看要困难，并且每次执行这样的查询时，您都会谴责自己正确地转义。 如果可能，请避免所有这些麻烦并使用准备好的语句（或绑定参数或参数化查询）。 这个想法是允许数据访问库正确转义值。

例如，在 PHP 中，使用 mysqli：

$db_connection = new mysqli("localhost", "user", "pass", "db");
$statement = $db_connection->prepare("SELECT thing FROM stuff WHERE id = ?");
$statement->bind_param("i", $user_id); //$user_id is an integer which goes 
                                       //in place of ?
$statement->execute();

Answer 3

如果 $user_id 被转义，那么您应该不会受到 SQL 注入的攻击。

在这种情况下，我还要确保 $user_id 是数字或整数（取决于所需的确切类型）。 您应始终将数据限制为最严格的类型。

Answer 4

如果它被正确转义和验证，那么就不会有问题。

当没有正确转义或验证时就会出现问题。 这可能是由于草率编码或疏忽造成的。

问题不在于特定实例，而在于模式。 这种模式使得 SQL 注入成为可能，而另一种模式则使其不可能。

Answer 5

所有答案都很好而且正确，但我觉得我需要补充一点，prepare/execute 范例也不是唯一解决方案。 您应该有一个数据库抽象层，而不是直接使用库函数，这样的层是显式转义字符串参数的好地方，无论您是否让prepare这样做，或者你自己做。

Answer 6

我认为“正确逃脱”是这里的关键词。 在您的最后一个问题中，我假设您的代码是从您的产品中复制粘贴的代码，并且由于您询问了有关三个表连接的问题，我还假设您没有进行正确的转义，因此我对 SQL 注入攻击发表了评论。

为了回答您的问题，正如这里很多人所描述的那样，如果变量已被“正确转义”，那么您就没有问题。 但为什么要这样做呢？ 正如一些人指出的那样，有时正确逃脱并不是一件简单的事情。 PHP 中有一些模式和库使 SQL 注入变得不可能，为什么我们不直接使用它呢？ （我还故意假设你的代码实际上是 PHP）。 Vinko Vrsalovic 答案可能会给你一些想法如何解决这个问题。

Answer 7

这样的声明实际上并不是一个问题，它是“安全的”，但是我不知道你是如何做到这一点的（API 堆栈上一级）。 如果 $user_id 使用字符串操作插入到语句中（就像让 Php 自动填写语句一样），那么它很危险。

如果使用绑定 API 进行了填写，那么您就可以开始了。