如果用户输入未经修改就插入到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;--')

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


当前回答

对于那些不确定如何使用PDO(来自mysql_函数)的人,我制作了一个非常非常简单的PDO包装器,它是一个单独的文件。它的存在是为了显示应用程序需要做的所有常见事情是多么容易。适用于PostgreSQL、MySQL和SQLite。

基本上,在阅读手册的同时阅读它,了解如何在实际生活中使用PDO函数,从而使以所需格式存储和检索值变得简单。

我想要一列$count=数据库::列('SELECT count(*)FROM `user`');我想要一个数组(key=>value)结果(即,用于生成一个选择框)$pairs=数据库::pairs('SELECT `id',`username`FROM`user`');我想要单行结果$user=DB::行('SELECT*FROM`user`WHERE `id`=?',数组($user_id));我想要一系列结果$banned_users=DB::fetch('SELECT*FROM `user`WHERE `banned`=?',数组('RUE'));

其他回答

如果可能,请转换参数的类型。但它只适用于像int、bool和float这样的简单类型。

$unsafe_variable = $_POST['user_id'];

$safe_variable = (int)$unsafe_variable ;

mysqli_query($conn, "INSERT INTO table (column) VALUES ('" . $safe_variable . "')");

正如你所看到的,人们建议你最多使用准备好的陈述。这并没有错,但如果每个进程只执行一次查询,则会有轻微的性能损失。

我正面临这个问题,但我认为我以非常复杂的方式解决了它——黑客避免使用引号的方式。我将其与模拟的准备语句结合使用。我使用它来防止各种可能的SQL注入攻击。

我的方法:

如果您希望输入是整数,请确保它真的是整数。在像PHP这样的变量类型语言中,这一点非常重要。例如,您可以使用这个非常简单但功能强大的解决方案:sprintf(“SELECT 1,2,3 FROM table WHERE 4=%u”,$input);如果你对整数十六进制有任何期望,如果你对它十六进制,你将完全逃避所有输入。在C/C++中有一个名为mysql_hex_string()的函数,在PHP中可以使用bin2hex()。不用担心转义字符串的大小是其原始长度的2倍,因为即使使用mysql_real_ascape_string,PHP也必须分配相同的容量((2*input_length)+1),这是相同的。这种十六进制方法通常在传输二进制数据时使用,但我认为没有理由不对所有数据使用它来防止SQL注入攻击。请注意,您必须在数据前面加上0x,或者改用MySQL函数UNHEX。

例如,查询:

SELECT password FROM users WHERE name = 'root';

将变成:

SELECT password FROM users WHERE name = 0x726f6f74;

or

SELECT password FROM users WHERE name = UNHEX('726f6f74');

Hex是完美的逃脱。无法注射。

UNHEX函数与0x前缀之间的差异

评论中有一些讨论,所以我最后想说清楚。这两种方法非常相似,但在某些方面略有不同:

0x前缀只能用于char、varchar、text、block、binary等数据列。此外,如果要插入空字符串,则其使用有点复杂。您必须将其完全替换为“”,否则会出现错误。

UNHEX()适用于任何列;你不必担心空字符串。


十六进制方法通常用作攻击

注意,这种十六进制方法通常被用作SQL注入攻击,其中整数就像字符串一样,并且只使用mysql_real_aescape_string进行转义。然后可以避免使用引号。

例如,如果你只是这样做:

"SELECT title FROM article WHERE id = " . mysql_real_escape_string($_GET["id"])

攻击很容易给你注射。考虑从脚本返回的以下注入代码:

SELECT ... WHERE id = -1 UNION ALL SELECT table_name FROM information_schema.tables;

现在只提取表结构:

SELECT ... WHERE id = -1 UNION ALL SELECT column_name FROM information_schema.column WHERE table_name = __0x61727469636c65__;

然后只需选择所需的数据。是不是很酷?

但如果可注入站点的编码器将其十六进制,则不可能进行注入,因为查询将如下所示:

SELECT ... WHERE id = UNHEX('2d312075...3635');

我认为如果有人想使用PHP和MySQL或其他数据库服务器:

考虑一下学习PDO(PHP数据对象)——它是一个数据库访问层,提供了访问多个数据库的统一方法。考虑学习MySQLi


库示例:

----个人数字助理

-----没有占位符-SQL注入时机成熟!这很糟糕

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values ($name, $addr, $city)");

-----未命名占位符

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) values (?, ?, ?);

-----命名占位符

$request = $pdoConnection->("INSERT INTO parents (name, addr, city) value (:name, :addr, :city)");

---MySQLi

$request = $mysqliConnection->prepare('
       SELECT * FROM trainers
       WHERE name = ?
       AND email = ?
       AND last_login > ?');

    $query->bind_param('first_param', 'second_param', $mail, time() - 3600);
    $query->execute();

P.S:

PDO轻松赢得了这场战斗。支持12个不同的数据库驱动程序和命名参数,我们可以习惯它的API。从安全的角度来看,只要开发人员按照应该使用的方式使用它们,它们都是安全的

安全警告:此答案不符合安全最佳实践。转义不足以防止SQL注入,请改用准备好的语句。使用以下概述的策略,风险自负。(此外,在PHP7中删除了mysql_real_ascape_string()。)不推荐使用警告:mysql扩展目前不推荐使用。我们建议使用PDO扩展

我使用三种不同的方法来防止我的web应用程序容易受到SQL注入的攻击。

使用mysql_real_aescape_string(),这是PHP中的一个预定义函数,此代码为以下字符添加反斜杠:\x00、\n、\r、\、'、“和\x1a。将输入值作为参数传递,以最大限度地减少SQL注入的机会。最先进的方法是使用PDO。

我希望这对你有帮助。

考虑以下查询:

$iId=mysql_real_ascape_string(“1或1=1”);$sSql=“SELECT*FROM table WHERE id=$iId”;

mysql_real_aescape_string()在这里不起保护作用。如果在查询中的变量周围使用单引号(“”),则可以防止这种情况发生。下面是一个解决方案:

$iId=(int)mysql_real_aescape_string(“1或1=1”);$sSql=“SELECT*FROM table WHERE id=$iId”;

这个问题有一些很好的答案。

我建议,使用PDO是最好的选择。

编辑:

自PHP 5.5.0起,mysql_real_aescape_string()已被弃用。使用mysqli或PDO。

mysql_real_aescape_string()的替代方法是

string mysqli_real_escape_string ( mysqli $link , string $escapestr )

例子:

$iId = $mysqli->real_escape_string("1 OR 1=1");
$mysqli->query("SELECT * FROM table WHERE id = $iId");

这里的每个答案都只涵盖了问题的一部分。事实上,有四个不同的查询部分可以动态添加到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注入的措施(如果适用)。