如何防止PHP中的SQL注入？

提问者：小点点

如何防止PHP中的SQL注入？

如果用户输入未经修改就插入SQL查询，那么应用程序就容易受到SQL注入的攻击，如以下示例所示:

$unsafe_variable = $_POST['user_input']; 

mysql_query("INSERT INTO `table` (`column`) VALUES ('$unsafe_variable')");

这是因为用户可以输入类似value')；DROP TABLE TABLE；--的内容，然后查询变为:

INSERT INTO `table` (`column`) VALUES('value'); DROP TABLE table;--')

有什么办法可以防止这种情况发生呢？

共3个答案

匿名用户

使用准备好的语句和参数化查询。这些SQL语句与任何参数分开发送到数据库服务器并由数据库服务器解析。这样攻击者就不可能注入恶意SQL。

您基本上有两种选择来实现这一点:

使用PDO（对于任何支持的数据库驱动程序）:

$stmt = $pdo->prepare('SELECT * FROM employees WHERE name = :name');

$stmt->execute([ 'name' => $name ]);

foreach ($stmt as $row) {
    // Do something with $row
}

使用MySQLi（用于MySQL）:

$stmt = $dbConnection->prepare('SELECT * FROM employees WHERE name = ?');
$stmt->bind_param('s', $name); // 's' specifies the variable type => 'string'

$stmt->execute();

$result = $stmt->get_result();
while ($row = $result->fetch_assoc()) {
    // Do something with $row
}

如果您连接的是MySQL以外的数据库，则可以参考驱动程序特定的第二个选项（例如，对于PostgreSQL，pg_prepare()和pg_execute())。 PDO是通用选项。

注意，当使用pdo访问MySQL数据库时，默认情况下不使用real prepared语句。要解决这个问题，您必须禁用对准备好的语句的模拟。使用PDO创建连接的一个示例是:

$dbConnection = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'password');

$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

在上面的示例中，错误模式并不是严格必需的，但是建议添加它。这样，当出现错误时，脚本就不会以致命错误停止。并且它使开发人员有机会将捕获任何错误（这些错误是抛出n为PDOExceptions）捕获。

但是，强制执行的是第一行setAttribute()，它告诉PDO禁用模拟的准备语句并使用真正的准备语句。这样可以确保在将语句和值发送到MySQL服务器之前，PHP不会对其进行解析（不给可能的攻击者注入恶意SQL的机会）。

虽然您可以在构造函数的选项中设置charset，但需要注意的是，PHP的“旧”版本(5.3.6之前的版本）在DSN中静默地忽略了charset参数。

传递给prepare的SQL语句由数据库服务器解析和编译。通过指定参数（或者是？，或者是像上面示例中的:name这样的命名参数），您可以告诉数据库引擎您想要筛选的位置。然后当您调用execute时，准备好的语句与您指定的参数值组合在一起。

这里重要的是参数值是与编译后的语句组合在一起的，而不是一个SQL字符串。 SQL注入的工作方式是在脚本创建要发送到数据库的SQL时诱骗脚本包含恶意字符串。因此，通过将实际的SQL与参数分开发送，您可以限制以您不想要的结果结束的风险。

在使用准备好的语句时发送的任何参数都将被视为字符串（当然，数据库引擎可能会进行一些优化，因此参数也可能以数字结束）。在上面的示例中，如果$name变量包含“Sarah”； DELETE FROM Employees结果只是搜索字符串“'Sarah'；DELETE FROM Employees”，您不会得到一个空表。

使用准备好的语句的另一个好处是，如果您在同一会话中多次执行同一语句，它将只被解析和编译一次，从而提高了速度。

哦，既然您询问了如何执行插入操作，下面是一个示例（使用PDO）:

$preparedStatement = $db->prepare('INSERT INTO table (column) VALUES (:column)');

$preparedStatement->execute([ 'column' => $unsafeValue ]);

虽然您仍然可以对查询参数使用准备好的语句，但动态查询本身的结构不能参数化，某些查询功能也不能参数化。

对于这些特定场景，最好的做法是使用白名单筛选器来限制可能的值。

// Value whitelist
// $dir can only be 'DESC', otherwise it will be 'ASC'
if (empty($dir) || $dir !== 'DESC') {
   $dir = 'ASC';
}

匿名用户

不推荐使用的警告:这个答案的示例代码（与问题的示例代码一样）使用PHP的mysql扩展，该扩展在PHP 5.5.0中是不推荐使用的，在PHP 7.0.0中被完全删除。

安全警告:此答案不符合安全最佳实践。转义不足以防止SQL注入，请改用准备好的语句。使用下面概述的策略，风险由您自己承担。（另外，mysql_real_escape_string()在PHP 7中被删除。）

如果您使用的是最新版本的PHP，下面列出的mysql_real_escape_string选项将不再可用（尽管mysqli::escape_string是现代的等效选项）。现在，mysql_real_escape_string选项只能用于旧版本PHP上的遗留代码。

您有两种选择:转义unsafe_variable中的特殊字符，或者使用参数化查询。两者都可以保护您免受SQL注入的影响。参数化查询被认为是更好的实践，但需要在PHP中更改为更新的MySQL扩展才能使用它。

我们会先把下面的撞击绳从一个逃出来。

//Connect

$unsafe_variable = $_POST["user-input"];
$safe_variable = mysql_real_escape_string($unsafe_variable);

mysql_query("INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

//Disconnect

另请参阅mysql_real_escape_string函数的详细信息。

要使用参数化查询，需要使用MySQLi而不是MySQL函数。要重写示例，我们需要如下内容。

<?php
    $mysqli = new mysqli("server", "username", "password", "database_name");

    // TODO - Check that connection was successful.

    $unsafe_variable = $_POST["user-input"];

    $stmt = $mysqli->prepare("INSERT INTO table (column) VALUES (?)");

    // TODO check that $stmt creation succeeded

    // "s" means the database expects a string
    $stmt->bind_param("s", $unsafe_variable);

    $stmt->execute();

    $stmt->close();

    $mysqli->close();
?>

您需要阅读的关键函数是mysqli::prepare。

另外，正如其他人所建议的，您可能会发现使用PDO之类的东西来增强抽象层是有用的/更容易的。

请注意，您所问的案例是一个相当简单的案例，更复杂的案例可能需要更复杂的方法。特别是:

如果您希望根据用户输入更改SQL的结构，那么参数化查询将无济于事，并且所需的转义不在mysql_real_escape_string中涵盖。在这种情况下，最好通过白名单传递用户输入，以确保只允许“安全”值通过。
如果在条件中使用来自用户输入的整数并采用mysql_real_escape_string方法，则会遇到下面注释中用多项式描述的问题。这种情况比较棘手，因为整数不会被引号包围，所以您可以通过验证用户输入只包含数字来处理。
可能还有其他我不知道的案例。您可能会发现，对于您可能遇到的一些更微妙的问题，这是一个有用的资源。

匿名用户

这里的每一个答案都只涵盖了问题的一部分。实际上，有四个不同的查询部分可以动态地添加到SQL中:-

字符串
数字
标识符
语法关键字

而准备好的发言只涉及其中两个。

但有时我们必须使查询更加动态，同时添加运算符或标识符。因此，我们需要不同的保护技术。

通常，这样的保护方法基于白名单。

在这种情况下，每个动态参数都应该硬编码在脚本中，并从该集合中选择。例如，要做动态下单:

$orders  = array("name", "price", "qty"); // Field names
$key = array_search($_GET['sort'], $orders)); // if we have such a name
$orderby = $orders[$key]; // If not, first one will be set automatically. 
$query = "SELECT * FROM `table` ORDER BY $orderby"; // Value is safe

为了简化这个过程，我编写了一个白名单助手函数，它在一行中完成所有工作:

$orderby = white_list($_GET['orderby'], "name", ["name","price","qty"], "Invalid field name");
$query  = "SELECT * FROM `table` ORDER BY `$orderby`"; // sound and safe

还有另一种保护标识符的方法--转义，但我更倾向于使用白名单作为一种更健壮，更明确的方法。然而，只要您有一个引号，您就可以转义引号字符以确保其安全。例如，默认情况下，对于mysql，您必须将引号字符加倍以转义它。对于其他DBMS，转义规则将有所不同。

但是，SQL语法关键字（例如和，desc等）还是有问题的，但是在这种情况下，白名单似乎是唯一的方法。

因此，一般性建议的措辞可为

任何表示SQL数据文本（或者，简单地说，SQL字符串或数字）的变量都必须通过准备好的语句添加。没有例外。
任何其他查询部分（如SQL关键字，表或字段名或运算符）都必须通过白名单筛选。

尽管对于SQL注入保护的最佳实践已经达成了共识，但仍然存在许多不好的实践。而且其中一些在PHP用户的头脑中根深蒂固。例如，就在这个页面上（虽然大多数访问者看不到）有80多个被删除的答案--这些答案都是由于质量差或推广不良和过时的做法而被社区删除的。更糟糕的是，一些糟糕的答案并没有被删除，而是得到了繁荣。

例如，（1）有（2）仍然（3）很多（4）答案（5），包括第二个被支持最多的答案建议手动字符串转义--这是一种过时的方法，被证明是不安全的。

或者，有一个稍微好一点的答案，建议使用另一种字符串格式化方法，甚至夸耀它是最终的灵丹妙药。当然，事实并非如此。这种方法并不比常规的字符串格式化好，但它保留了它的所有缺点:它只适用于字符串，而且，与任何其他手动格式化一样，它本质上是可选的，非强制性的措施，容易出现任何类型的人为错误。

我认为这一切都是因为一种古老的迷信，这种迷信得到了OWASP或PHP手册等权威的支持，它们宣称无论什么“逃逸”和保护免受SQL注入之间是平等的。

不管PHP手册多年来是怎么说的，*_escape_string绝不会使数据安全，而且从来没有打算这样做。除了对字符串以外的任何SQL部分都无用之外，手动转义也是错误的，因为它是手动的，而不是自动的。

而OWASP使其更糟，强调转义用户输入，这完全是无稽之谈:在注入保护的上下文中不应该有这样的词。每一个变量都有潜在的危险--无论其来源！或者，换句话说--每个变量都必须经过适当的格式化才能放入查询--再一次不管是源。重要的是目的地。当开发人员开始区分绵羊和山羊时（考虑某个特定变量是否“安全”），他/她就迈出了走向灾难的第一步。更不用说，甚至连措辞都暗示了在入口点处的大量逃逸，就像非常神奇的引号功能--已经被鄙视，反对和删除了。

因此，与任何“转义”不同的是，准备语句是一种确实可以防止SQL注入（如果适用）的度量。