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

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


当前回答

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

警告:mysql扩展名此时被删除。我们建议使用PDO扩展

使用此PHP函数mysql_escape_string(),您可以快速获得良好的预防效果。

例如:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."'

mysql_escape_string-转义用于mysql_query的字符串

为了更好地预防,您可以在末尾添加。。。

wHERE 1=1   or  LIMIT 1

最后你得到:

SELECT * FROM users WHERE name = '".mysql_escape_string($name_from_html_form)."' LIMIT 1

其他回答

对于那些不确定如何使用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'));

关于许多有用的答案,我希望为这一主题增添一些价值。

SQL注入是一种可以通过用户输入(由用户填充然后在查询中使用的输入)进行的攻击。SQL注入模式是正确的查询语法,而我们可以称之为:错误的查询是由于错误的原因,我们假设可能有坏人试图获取影响安全性(机密性、完整性和可用性)三个原则的秘密信息(绕过访问控制)。

现在,我们的重点是防止安全威胁,如SQL注入攻击,问题是(如何使用PHP防止SQL注入攻击),更现实的是,数据过滤或清除输入数据是在这样的查询中使用用户输入数据时的情况,而不是使用PHP或任何其他编程语言,或者更多人建议使用现代技术,如prepared语句或当前支持SQL注入预防的任何其他工具,是否认为这些工具不再可用?如何保护您的应用程序?

我反对SQL注入的方法是:在将用户输入数据发送到数据库之前(在任何查询中使用之前)清除用户输入数据。

的数据筛选(将不安全数据转换为安全数据)

考虑PDO和MySQLi不可用。如何保护应用程序?你强迫我使用它们吗?PHP以外的其他语言呢?我更愿意提供一般性的想法,因为它可以用于更广泛的边界,而不仅仅是用于特定的语言。

SQL用户(限制用户权限):最常见的SQL操作是(SELECT、UPDATE、INSERT),那么,为什么要将UPDATE权限授予不需要它的用户呢?例如,登录和搜索页面只使用SELECT,那么,为什么在这些页面中使用具有高权限的DB用户?

规则:不要为所有权限创建一个数据库用户。对于所有SQL操作,您可以创建类似(deluser、selectuser、updateuser)的方案作为用户名,以方便使用。

参见最低特权原则。

数据过滤:在构建任何查询用户输入之前,应该对其进行验证和过滤。对于程序员来说,为每个用户输入变量定义一些财产很重要:数据类型、数据模式和数据长度。一个介于(x和y)之间的数字字段必须使用精确的规则进行精确验证,对于一个字符串(文本)的字段:模式就是这种情况,例如,用户名只能包含一些字符,比如[A-zA-Z0-9_-.]。长度在(x和n)之间变化,其中x和n(整数,x<=n)。规则:创建精确的过滤器和验证规则是我的最佳实践。使用其他工具:在这里,我也同意您的观点,即准备好的语句(参数化查询)和存储过程。这里的缺点是这些方法需要高级技能,而大多数用户并不具备这些技能。这里的基本思想是区分SQL查询和内部使用的数据。这两种方法甚至可以用于不安全的数据,因为这里的用户输入数据不会向原始查询添加任何内容,例如(any或x=x)。

有关详细信息,请阅读OWASP SQL注入预防秘籍。

现在,如果您是高级用户,可以开始使用这种防御,但是对于初学者来说,如果他们不能快速实现存储过程并准备好语句,最好尽可能过滤输入数据。

最后,让我们考虑用户在下面发送此文本,而不是输入其用户名:

[1] UNION SELECT IF(SUBSTRING(Password,1,1)='2',BENCHMARK(100000,SHA1(1)),0) User,Password FROM mysql.user WHERE User = 'root'

可以在没有任何准备好的语句和存储过程的情况下尽早检查此输入,但为了安全起见,在用户数据过滤和验证之后开始使用它们。

最后一点是检测需要更多努力和复杂性的意外行为;它不建议用于普通的web应用程序。

上述用户输入中的意外行为是SELECT、UNION、IF、SUBSTRING、BENCHMARK、SHA和root。一旦检测到这些单词,就可以避免输入。

更新1:

一位用户评论说,这篇文章毫无用处,好吧!以下是OWASP.ORG提供的内容:

主要防御措施:选项#1:使用准备好的语句(参数化查询)选项#2:使用存储过程选项#3:转义所有用户提供的输入其他防御措施:同时强制:最低权限同时执行:白名单输入验证

正如你可能知道的,声称一篇文章应该有一个有效的论据支持,至少要有一个引用!否则,这被认为是一次攻击和一次糟糕的索赔!

更新2:

从PHP手册中,PHP:准备好的语句-手册:

转义和SQL注入绑定变量将由服务器自动转义。这个服务器将其转义值插入到语句模板。必须向绑定变量类型的服务器,以创建适当的转变有关详细信息,请参见mysqli_stmt_bind_param()函数信息服务器中的值的自动转义有时是被认为是防止SQL注入的安全功能。相同的在以下情况下,可以使用未准备的报表实现安全程度输入值被正确转义。

更新3:

我创建了测试用例,以了解PDO和MySQLi在使用准备好的语句时如何将查询发送到MySQL服务器:

PDO:

$user = "''1''"; // Malicious keyword
$sql = 'SELECT * FROM awa_user WHERE userame =:username';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array(':username' => $user));

查询日志:

189查询SELECT*FROM awa_user WHERE username=“\”\“1”\“”189退出

MySQLi:

$stmt = $mysqli->prepare("SELECT * FROM awa_user WHERE username =?")) {
$stmt->bind_param("s", $user);
$user = "''1''";
$stmt->execute();

查询日志:

188准备SELECT*FROM awa_user WHERE username=?188执行SELECT*FROM awa_user WHERE用户名=“\”\“1”\“”188退出

很明显,准备好的语句也在逃避数据,而不是其他。

同样如上述陈述中所述,

服务器内值的自动转义有时被认为是防止SQL注入的安全功能。如果输入值被正确转义,则可以使用未准备的语句实现相同程度的安全性

因此,这证明了在发送任何查询之前对整数值进行数据验证(如intval())是一个好主意。此外,在发送查询之前防止恶意用户数据是一种正确有效的方法。

请参阅这个问题以了解更多详细信息:PDO向MySQL发送原始查询,而Mysqli发送准备好的查询,两者都产生相同的结果

参考文献:

SQL注入秘籍SQL注入信息安全安全原则数据验证

警告:本答案中描述的方法仅适用于非常特定的场景,并不安全,因为SQL注入攻击不仅仅依赖于能够注入X=Y。

如果攻击者试图通过PHP的$_GET变量或URL的查询字符串侵入表单,如果他们不安全,您将能够抓住他们。

RewriteCond %{QUERY_STRING} ([0-9]+)=([0-9]+)
RewriteRule ^(.*) ^/track.php

因为1=1、2=2、1=2、2=1、1+1=2等……是攻击者SQL数据库的常见问题。也许它也被许多黑客应用程序使用。

但您必须小心,不能从站点重写安全查询。上面的代码为您提供了一个提示,可以重写或重定向(这取决于您)将特定的动态查询字符串黑客入侵到一个页面中,该页面将存储攻击者的IP地址,甚至是他们的COOKIES、历史记录、浏览器或任何其他敏感信息,因此您可以稍后通过禁用他们的帐户或联系当局来处理他们。

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

$unsafe_variable = $_POST['user_id'];

$safe_variable = (int)$unsafe_variable ;

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

我建议使用PDO(PHP数据对象)运行参数化SQL查询。

这不仅可以防止SQL注入,还可以加快查询速度。

而且,通过使用PDO而不是mysql_、mysqli_和pgsql_函数,可以使应用程序从数据库中抽象出一点,这是很少需要切换数据库提供程序的情况。