为什么不应该使用mysql_*函数的技术原因是什么?(例如mysql_query()、mysql_connect()或mysql_real_ascape_string())?
为什么我要使用其他东西,即使它们在我的网站上工作?
如果它们在我的网站上不起作用,为什么我会出现这样的错误
警告:mysql_connect():没有这样的文件或目录
为什么不应该使用mysql_*函数的技术原因是什么?(例如mysql_query()、mysql_connect()或mysql_real_ascape_string())?
为什么我要使用其他东西,即使它们在我的网站上工作?
如果它们在我的网站上不起作用,为什么我会出现这样的错误
警告:mysql_connect():没有这样的文件或目录
当前回答
首先,让我们从我们给每个人的标准评论开始:
请不要在新代码中使用mysql_*函数。它们不再被维护,并被正式弃用。看到红盒子了吗?学习准备好的语句,并使用PDO或MySQLi-本文将帮助您决定使用哪一种。如果你选择PDO,这里有一个很好的教程。
让我们一句一句地来解释一下:
它们不再被维护,并被正式弃用这意味着PHP社区正在逐渐放弃对这些非常古老的函数的支持。它们很可能在未来(最近)版本的PHP中不存在!在不久的将来,继续使用这些函数可能会破坏代码。新!-ext/mysql从PHP 5.5开始正式被弃用!更新!ext/mysql已在PHP7中删除。相反,你应该学习准备好的陈述mysql_*扩展不支持准备好的语句,这是针对SQL注入的一种非常有效的对策。它修复了依赖MySQL的应用程序中的一个非常严重的漏洞,该漏洞允许攻击者访问您的脚本并对您的数据库执行任何可能的查询。有关更多信息,请参阅如何防止PHP中的SQL注入?看到红盒子了吗?当您转到任何mysql函数手册页面时,都会看到一个红色框,说明不应该再使用它。使用PDO或MySQLi有更好、更健壮和构建良好的替代方案,PDO-PHP数据库对象,它为数据库交互提供了完整的OOP方法,以及MySQLi,它是MySQL特有的改进。
其他回答
MySQL扩展是三个扩展中最古老的,也是开发人员用来与MySQL通信的原始方式。由于PHP和MySQL的更新版本都有改进,因此现在不推荐使用此扩展,而支持其他两种替代方案。
MySQLi是用于处理MySQL数据库的“改进”扩展。它利用了MySQL服务器较新版本中可用的功能,向开发人员公开了面向功能和面向对象的界面,并做了一些其他漂亮的事情。PDO提供了一个API,它整合了以前分布在主要数据库访问扩展(即MySQL、PostgreSQL、SQLite、MSSQL等)中的大部分功能。该接口为程序员提供高级对象,以处理数据库连接、查询和结果集,低级驱动程序与数据库服务器进行通信和资源处理。PDO正在进行大量的讨论和工作,它被认为是使用现代专业代码处理数据库的适当方法。
首先,让我们从我们给每个人的标准评论开始:
请不要在新代码中使用mysql_*函数。它们不再被维护,并被正式弃用。看到红盒子了吗?学习准备好的语句,并使用PDO或MySQLi-本文将帮助您决定使用哪一种。如果你选择PDO,这里有一个很好的教程。
让我们一句一句地来解释一下:
它们不再被维护,并被正式弃用这意味着PHP社区正在逐渐放弃对这些非常古老的函数的支持。它们很可能在未来(最近)版本的PHP中不存在!在不久的将来,继续使用这些函数可能会破坏代码。新!-ext/mysql从PHP 5.5开始正式被弃用!更新!ext/mysql已在PHP7中删除。相反,你应该学习准备好的陈述mysql_*扩展不支持准备好的语句,这是针对SQL注入的一种非常有效的对策。它修复了依赖MySQL的应用程序中的一个非常严重的漏洞,该漏洞允许攻击者访问您的脚本并对您的数据库执行任何可能的查询。有关更多信息,请参阅如何防止PHP中的SQL注入?看到红盒子了吗?当您转到任何mysql函数手册页面时,都会看到一个红色框,说明不应该再使用它。使用PDO或MySQLi有更好、更健壮和构建良好的替代方案,PDO-PHP数据库对象,它为数据库交互提供了完整的OOP方法,以及MySQLi,它是MySQL特有的改进。
编写这个答案是为了说明绕过编写糟糕的PHP用户验证代码是多么微不足道,这些攻击是如何工作的(以及使用什么),以及如何用一个安全的准备好的语句替换旧的MySQL函数,以及基本上,为什么StackOverflow用户(可能有很多代表)会对新用户狂吠,询问如何改进他们的代码。
首先,请随意创建这个测试mysql数据库(我已经调用了我的prep):
mysql> create table users(
-> id int(2) primary key auto_increment,
-> userid tinytext,
-> pass tinytext);
Query OK, 0 rows affected (0.05 sec)
mysql> insert into users values(null, 'Fluffeh', 'mypass');
Query OK, 1 row affected (0.04 sec)
mysql> create user 'prepared'@'localhost' identified by 'example';
Query OK, 0 rows affected (0.01 sec)
mysql> grant all privileges on prep.* to 'prepared'@'localhost' with grant option;
Query OK, 0 rows affected (0.00 sec)
完成后,我们可以转到PHP代码。
让我们假设以下脚本是网站管理员的验证过程(如果您复制并将其用于测试,则简化但有效):
<?php
if(!empty($_POST['user']))
{
$user=$_POST['user'];
}
else
{
$user='bob';
}
if(!empty($_POST['pass']))
{
$pass=$_POST['pass'];
}
else
{
$pass='bob';
}
$database='prep';
$link=mysql_connect('localhost', 'prepared', 'example');
mysql_select_db($database) or die( "Unable to select database");
$sql="select id, userid, pass from users where userid='$user' and pass='$pass'";
//echo $sql."<br><br>";
$result=mysql_query($sql);
$isAdmin=false;
while ($row = mysql_fetch_assoc($result)) {
echo "My id is ".$row['id']." and my username is ".$row['userid']." and lastly, my password is ".$row['pass']."<br>";
$isAdmin=true;
// We have correctly matched the Username and Password
// Lets give this person full access
}
if($isAdmin)
{
echo "The check passed. We have a verified admin!<br>";
}
else
{
echo "You could not be verified. Please try again...<br>";
}
mysql_close($link);
?>
<form name="exploited" method='post'>
User: <input type='text' name='user'><br>
Pass: <input type='text' name='pass'><br>
<input type='submit'>
</form>
乍一看似乎足够合理。
用户必须输入登录名和密码,对吗?
Brilliant,现在输入以下内容:
user: bob
pass: somePass
并提交。
输出如下:
You could not be verified. Please try again...
超级的按照预期工作,现在让我们尝试实际的用户名和密码:
user: Fluffeh
pass: mypass
太神了大家好,代码正确地验证了管理员。太完美了!
嗯,不是真的。假设用户是一个聪明的小人物。让我们说这个人是我。
输入以下内容:
user: bob
pass: n' or 1=1 or 'm=m
输出为:
The check passed. We have a verified admin!
恭喜你,你刚刚允许我输入一个假用户名和一个假密码,进入你的超级保护管理员专用部分。说真的,如果你不相信我的话,用我提供的代码创建数据库,然后运行这个PHP代码——乍一看,它确实很好地验证了用户名和密码。
所以,作为回答,这就是为什么你被黄了。
所以,让我们看看出了什么问题,以及为什么我刚刚进入了你的超级管理员专用蝙蝠洞。我猜了一下,假设你对输入不小心,直接将它们传递到数据库。我构建输入的方式会改变您实际运行的查询。那么,它应该是什么,最终是什么?
select id, userid, pass from users where userid='$user' and pass='$pass'
这是一个查询,但当我们用实际使用的输入替换变量时,我们会得到以下结果:
select id, userid, pass from users where userid='bob' and pass='n' or 1=1 or 'm=m'
看看我是如何构造我的“密码”的,这样它将首先关闭密码周围的单引号,然后引入一个全新的比较?然后为了安全起见,我添加了另一个“字符串”,这样单引号就可以像我们最初的代码中所期望的那样关闭。
然而,这不是人们现在对你大喊大叫,而是向你展示如何使代码更安全。
好吧,那么出了什么问题,我们该怎么解决?
这是典型的SQL注入攻击。这是最简单的方法之一。在攻击向量的规模上,这是一个蹒跚学步的孩子攻击坦克并获胜。
那么,我们如何保护您神圣的管理部分并使其变得美观和安全?首先要做的是停止使用那些非常陈旧和过时的mysql_*函数。我知道,你遵循了你在网上找到的一个教程,它很有用,但它很旧,很过时,几分钟内,我就突破了它,甚至连汗都没流。
现在,您可以使用mysqli_或PDO了。我个人是PDO的忠实粉丝,因此我将在本答案的其余部分使用PDO。有赞成者和反对者,但我个人认为赞成者远远超过反对者。它可以跨多个数据库引擎进行移植-无论您使用的是MySQL还是Oracle,或者几乎是任何该死的东西-只需更改连接字符串,它就拥有了我们想要使用的所有花哨功能,而且非常干净。我喜欢干净。
现在,让我们再次看看这段代码,这次是使用PDO对象编写的:
<?php
if(!empty($_POST['user']))
{
$user=$_POST['user'];
}
else
{
$user='bob';
}
if(!empty($_POST['pass']))
{
$pass=$_POST['pass'];
}
else
{
$pass='bob';
}
$isAdmin=false;
$database='prep';
$pdo=new PDO ('mysql:host=localhost;dbname=prep', 'prepared', 'example');
$sql="select id, userid, pass from users where userid=:user and pass=:password";
$myPDO = $pdo->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
if($myPDO->execute(array(':user' => $user, ':password' => $pass)))
{
while($row=$myPDO->fetch(PDO::FETCH_ASSOC))
{
echo "My id is ".$row['id']." and my username is ".$row['userid']." and lastly, my password is ".$row['pass']."<br>";
$isAdmin=true;
// We have correctly matched the Username and Password
// Lets give this person full access
}
}
if($isAdmin)
{
echo "The check passed. We have a verified admin!<br>";
}
else
{
echo "You could not be verified. Please try again...<br>";
}
?>
<form name="exploited" method='post'>
User: <input type='text' name='user'><br>
Pass: <input type='text' name='pass'><br>
<input type='submit'>
</form>
主要区别在于不再有mysql_*函数。这一切都是通过PDO对象完成的,其次,它使用了一个准备好的语句。现在,你问一个准备好的陈述是什么?这是一种在运行查询之前告诉数据库我们要运行的查询的方式。在这种情况下,我们告诉数据库:“嗨,我要运行一个select语句,想要表用户的id、userid和pass,其中userid是一个变量,pass也是一个变量”。
然后,在execute语句中,我们向数据库传递一个数组,其中包含它现在需要的所有变量。
结果太棒了。让我们再次尝试以前的用户名和密码组合:
user: bob
pass: somePass
未验证用户。令人惊叹的
怎么样:
user: Fluffeh
pass: mypass
哦,我只是有点兴奋,它奏效了:支票通过了。我们有一个经过验证的管理员!
现在,让我们来试试聪明的家伙会输入的数据,以试图通过我们的小验证系统:
user: bob
pass: n' or 1=1 or 'm=m
这次,我们得到了以下结果:
You could not be verified. Please try again...
这就是为什么你在发布问题时会被吼——这是因为人们可以看到你的代码可以被绕过,甚至不用尝试。请使用这个问题和答案来改进代码,使其更安全,并使用当前的功能。
最后,这并不是说这是完美的代码。你可以做更多的事情来改进它,例如,使用散列密码,确保当你在数据库中存储敏感信息时,你不会以纯文本形式存储,并具有多个级别的验证-但实际上,如果你只是将旧的易注入代码改为这样,在编写好代码的过程中,你会很好的——事实上,你已经走到了这一步,而且还在阅读,这让我有一种希望,你不仅会在编写网站和应用程序时实现这种类型的代码,而且你可能会出去研究我刚才提到的其他东西——还有更多。写出你能写的最好的代码,而不是最基本的代码。
说到技术原因,只有几个,非常具体,很少使用。很可能你一生中都不会使用它们。也许我太无知了,但我从来没有机会使用它们
非阻塞异步查询返回多个结果集的存储过程加密(SSL)压缩
如果您需要,这些无疑是从mysql扩展转向更时尚、更现代的技术原因。
尽管如此,也有一些非技术性的问题,这会使您的体验更加困难
在现代PHP版本中进一步使用这些函数将引起不推荐使用的级别通知。它们可以简单地关闭。在不久的将来,它们可能会从默认的PHP构建中删除。也没什么大不了的,因为mydsql-ext将被迁移到PECL中,每个宿主都会很乐意用它来编译PHP,因为他们不想失去那些网站工作了几十年的客户。Stackoverflow社区的强烈抵抗。每次你提到这些诚实的功能时,你都会被告知它们是严格的禁忌。作为一个普通的PHP用户,您使用这些函数的想法很可能是错误的。就因为有这么多的教程和手册教你错误的方法。不是函数本身-我必须强调它-而是它们的使用方式。
后一个问题是一个问题。但是,在我看来,提议的解决方案也没有更好。在我看来,所有这些PHP用户都将立即学习如何正确处理SQL查询,这是一个过于理想化的梦想。他们很可能只是机械地将mysql_*更改为mysqli_*,保持方法不变。特别是因为mysqli使准备好的语句使用起来非常痛苦和麻烦。更不用说,本机准备的语句不足以防止SQL注入,mysqli和PDO都没有提供解决方案。
因此,我宁愿反对错误的做法,以正确的方式教育人们,而不是反对这种诚实的延伸。
此外,还有一些错误或不重要的原因,如
不支持存储过程(我们使用的是mysql_query(“CALL my_proc”);年龄)不支持交易(同上)不支持多个语句(谁需要它们?)不在积极发展中(那么,它对你有什么实际影响吗?)缺少OO接口(创建一个OO接口需要几个小时)不支持准备语句或参数化查询
最后一点很有趣。虽然mysql-ext不支持本机准备的语句,但出于安全考虑,它们不是必需的。我们可以使用手动处理的占位符轻松地伪造准备好的语句(就像PDO一样):
function paraQuery()
{
$args = func_get_args();
$query = array_shift($args);
$query = str_replace("%s","'%s'",$query);
foreach ($args as $key => $val)
{
$args[$key] = mysql_real_escape_string($val);
}
$query = vsprintf($query, $args);
$result = mysql_query($query);
if (!$result)
{
throw new Exception(mysql_error()." [$query]");
}
return $result;
}
$query = "SELECT * FROM table where a=%s AND b LIKE %s LIMIT %d";
$result = paraQuery($query, $a, "%$b%", $limit);
瞧,一切都是参数化和安全的。
但好吧,如果你不喜欢手册中的红色框,那么会出现一个选择问题:mysqli还是PDO?
答案如下:
如果您了解使用数据库抽象层并寻找API来创建抽象层的必要性,那么mysqli是一个非常好的选择,因为它确实支持许多mysql特有的特性。如果像绝大多数PHP用户一样,您在应用程序代码中正确使用原始API调用(这基本上是错误的做法),那么PDO是唯一的选择,因为这个扩展假装不仅仅是API,而是一个半DAL,仍然不完整,但提供了许多重要功能,其中两个功能使PDO与mysqli有着重要区别:与mysqli不同,PDO可以通过值绑定占位符,这使得动态构建的查询变得可行,而无需几个屏幕的代码。与mysqli不同,PDO总是可以在一个简单的普通数组中返回查询结果,而mysqli只能在mysqlnd安装上执行。
因此,如果你是一个普通的PHP用户,并且想在使用本机准备的语句时省去一大堆麻烦,那么PDO是唯一的选择。然而,PDO也不是银弹,也有其困难。因此,我为PDO标签wiki中的所有常见陷阱和复杂案例编写了解决方案
然而,每个谈论扩展的人总是忽略了关于Myqli和PDO的两个重要事实:
事先准备好的声明不是灵丹妙药。有一些动态标识符不能使用准备好的语句绑定。存在具有未知数量参数的动态查询,这使得查询构建成为一项困难的任务。mysqli_*和PDO函数都不应该出现在应用程序代码中。在它们和应用程序代码之间应该有一个抽象层,它将在内部完成绑定、循环、错误处理等所有肮脏的工作,使应用程序代码变得干干净净。特别是对于动态查询构建这样的复杂情况。
因此,仅仅切换到PDO或mysqli是不够的。必须使用ORM、查询生成器或任何数据库抽象类,而不是在代码中调用原始API函数。相反,如果在应用程序代码和mysqlAPI之间有一个抽象层,那么使用哪个引擎实际上并不重要。您可以使用mysql-ext,直到它被弃用,然后轻松地将抽象类重写到另一个引擎,使所有应用程序代码保持完整。
下面是基于我的safemysql类的一些示例,以说明这样的抽象类应该是什么样子的:
$city_ids = array(1,2,3);
$cities = $db->getCol("SELECT name FROM cities WHERE is IN(?a)", $city_ids);
将这一行与PDO所需的代码量进行比较。然后,将您需要的大量代码与原始Myqli准备的语句进行比较。请注意,错误处理、分析和查询日志已经内置并正在运行。
$insert = array('name' => 'John', 'surname' => "O'Hara");
$db->query("INSERT INTO users SET ?u", $insert);
将其与通常的PDO插入进行比较,当每个字段名重复六到十次时,在所有这些众多的命名占位符、绑定和查询定义中。
另一个例子:
$data = $db->getAll("SELECT * FROM goods ORDER BY ?n", $_GET['order']);
您很难找到PDO处理此类实际案例的示例。而且这太啰嗦了,很可能是不安全的。
所以,再一次,你应该关注的不仅仅是原始驱动程序,而是抽象类,它不仅适用于初学者手册中的愚蠢示例,也适用于解决任何现实问题。
因为(除其他原因外)要确保输入数据得到净化要困难得多。如果您使用参数化查询,就像使用PDO或mysqli一样,您可以完全避免风险。
例如,有人可以使用“enhzflep);drop table users”作为用户名。旧的函数将允许每个查询执行多个语句,所以像这种讨厌的bug可以删除整个表。
如果要使用mysqli的PDO,用户名将以“enhzflep);drop table user”结尾。
参见bobby-tables.com。