如果用户输入未经修改就插入到SQL查询中,则应用程序很容易受到SQL注入的攻击,如下例所示:

$unsafe_variable = $_POST['user_input']; 

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

这是因为用户可以输入类似值的内容);DROP TABLE表;--,并且查询变为:

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

可以采取什么措施防止这种情况发生?


当前回答

一个好主意是使用像Idiorm这样的对象关系映射器:

$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();

$user->first_name = 'Jamie';
$user->save();

$tweets = ORM::for_table('tweet')
    ->select('tweet.*')
    ->join('user', array(
        'user.id', '=', 'tweet.user_id'
    ))
    ->where_equal('user.username', 'j4mie')
    ->find_many();

foreach ($tweets as $tweet) {
    echo $tweet->text;
}

它不仅可以避免SQL注入,还可以避免语法错误!它还支持具有方法链接的模型集合,以一次过滤或将操作应用于多个结果和多个连接。

其他回答

不推荐的警告:这个答案的示例代码(与问题的示例代码一样)使用了PHP的MySQL扩展,该扩展在PHP 5.5.0中被弃用,在PHP 7.0.0中被完全删除。安全警告:此答案不符合安全最佳实践。转义不足以防止SQL注入,请改用准备好的语句。使用以下概述的策略,风险自负。(此外,在PHP7中删除了mysql_real_ascape_string()。)

使用PDO和MYSQLi是防止SQL注入的好方法,但如果您真的想使用MySQL函数和查询,最好使用

mysql_real_reape_string

$unsafe_variable = mysql_real_escape_string($_POST['user_input']);

还有更多的功能可以防止这种情况:比如识别-如果输入是字符串、数字、字符或数组,那么有很多内置函数可以检测这种情况。此外,最好使用这些函数来检查输入数据。

is_string(is_string)

$unsafe_variable = (is_string($_POST['user_input']) ? $_POST['user_input'] : '');

是数字(_N)

$unsafe_variable = (is_numeric($_POST['user_input']) ? $_POST['user_input'] : '');

使用这些函数来检查mysql_real_aescape_string中的输入数据要好得多。

要使用参数化查询,需要使用Mysqli或PDO。要用mysqli重写示例,我们需要以下内容。

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

$variable = $_POST["user-input"];
$stmt = $mysqli->prepare("INSERT INTO table (column) VALUES (?)");
// "s" means the database expects a string
$stmt->bind_param("s", $variable);
$stmt->execute();

你想在那里读到的关键函数是mysqli::prepare。

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

请注意,您询问的案例相当简单,更复杂的案例可能需要更复杂的方法。特别地:

如果您希望根据用户输入更改SQL的结构,参数化查询将不会有帮助,并且mysql_real_ascape_string不包含所需的转义。在这种情况下,最好通过白名单传递用户的输入,以确保只允许通过“安全”值。

使用PDO和准备好的查询。

($conn是PDO对象)

$stmt = $conn->prepare("INSERT INTO tbl VALUES(:id, :name)");
$stmt->bindValue(':id', $id);
$stmt->bindValue(':name', $name);
$stmt->execute();

这里的每个答案都只涵盖了问题的一部分。事实上,有四个不同的查询部分可以动态添加到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语法关键字(如AND、DESC等)仍然存在问题,但在这种情况下,白名单似乎是唯一的方法。

因此,一般性建议可表述为

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

使现代化

尽管人们对SQL注入保护的最佳做法达成了一致,但仍有许多不好的做法。其中一些过于深入人心。例如,就在这个页面上,有80多个被删除的答案(尽管大多数访问者看不见),这些答案都是由于质量不好或推广不良和过时的做法而被社区删除的。更糟糕的是,一些糟糕的答案并没有被删除,反而变得繁荣起来。

例如,有(1)仍然有(3)许多(4)答案(5),包括排名第二的、建议手动字符串转义的答案,这是一种过时的方法,被证明是不安全的。

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

我认为这一切都是因为一个非常古老的迷信,得到了OWASP或PHP手册等权威机构的支持,它宣称任何“逃逸”和SQL注入保护之间的平等。

不管PHP手册说了多少年,*_escape_string决不会使数据安全,也从来没有想过这样做。除了对字符串以外的任何SQL部分都没有用处之外,手动转义是错误的,因为它是手动的,而不是自动的。

OWASP使情况更糟,强调逃避用户输入,这完全是无稽之谈:在注射保护的上下文中不应该有这样的词。每一个变量都有潜在的危险——无论来源如何!或者,换句话说,每一个变量都必须经过正确的格式化才能放入查询中,无论其来源是什么。重要的是目的地。当开发人员开始将绵羊和山羊分开时(考虑某个特定变量是否“安全”),他/她就迈出了灾难的第一步。更不用说,就连措辞都建议在入口点进行大容量转义,这类似于非常神奇的引号功能——已经被轻视、弃用和删除。

因此,与任何“转义”不同的是,准备好的语句确实是防止SQL注入的措施(如果适用)。

不推荐的警告:这个答案的示例代码(与问题的示例代码一样)使用了PHP的MySQL扩展,该扩展在PHP 5.5.0中被弃用,在PHP 7.0.0中被完全删除。安全警告:此答案不符合安全最佳实践。转义不足以防止SQL注入,请改用准备好的语句。使用以下概述的策略,风险自负。(此外,在PHP7中删除了mysql_real_ascape_string()。)

参数化查询AND输入验证是一种方法。尽管使用了mysql_real_ascape_string(),但在许多情况下可能会发生SQL注入。

这些示例易受SQL注入攻击:

$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
RunQuery("SELECT userid, username FROM sql_injection_test LIMIT $offset, 10");

or

$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
RunQuery("SELECT userid, username FROM sql_injection_test ORDER BY `$order`");

在这两种情况下,都不能使用“”来保护封装。

来源:意外的SQL注入(当转义不够时)