PHP——自动SQL注入保护?
我最近接手了 PHP 应用程序的维护,我对 PHP 不太熟悉,但我在网站上看到的一些内容让我担心它可能容易受到 SQL 注入攻击。
例如,看看这段用于登录管理部分的代码是如何工作的:
$password = md5(HASH_SALT . $_POST['loginPass']);
$query = "SELECT * FROM `administrators` WHERE `active`='1' AND `email`='{$_POST['loginEmail']}' AND `password`='{$password}'";
$userInfo = db_fetch_array(db_query($query));
if($userInfo['id']) {
$_SESSION['adminLoggedIn'] = true;
// user is logged in, other junk happens here, not important
该网站的创建者制作了一个特殊的 db_query 方法和 db_fetch_array 方法,如下所示:
function db_query($qstring,$print=0) { return @mysql(DB_NAME,$qstring); }
function db_fetch_array($qhandle) { return @mysql_fetch_array($qhandle); }
现在,这让我认为我应该能够进行某种 SQL 注入攻击电子邮件地址如下:
' OR 'x'='x' LIMIT 1;
和一些随机密码。 当我在命令行上使用它时,我得到了一个管理用户,但是当我在应用程序中尝试它时,我得到了一个无效的用户名/密码错误,就像我应该的那样。
他们是否启用了某种全局 PHP 配置来阻止这些攻击?那要在哪里配置呢?
这是 PHP --version 信息:
# php --version
PHP 5.2.12 (cli) (built: Feb 28 2010 15:59:21)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with the ionCube PHP Loader v3.3.14, Copyright (c) 2002-2010, by ionCube Ltd., and
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies
I took over maintenance of a PHP app recently and I'm not super familiar with PHP but some of the things I've been seeing on the site are making me nervous that it could be vulnerable to a SQL injection attack.
For example, see how this code for logging into the administrative section works:
$password = md5(HASH_SALT . $_POST['loginPass']);
$query = "SELECT * FROM `administrators` WHERE `active`='1' AND `email`='{$_POST['loginEmail']}' AND `password`='{$password}'";
$userInfo = db_fetch_array(db_query($query));
if($userInfo['id']) {
$_SESSION['adminLoggedIn'] = true;
// user is logged in, other junk happens here, not important
The creators of the site made a special db_query method and db_fetch_array method, shown here:
function db_query($qstring,$print=0) { return @mysql(DB_NAME,$qstring); }
function db_fetch_array($qhandle) { return @mysql_fetch_array($qhandle); }
Now, this makes me think I should be able to do some sort of SQL injection attack with an email address like:
' OR 'x'='x' LIMIT 1;
and some random password.
When I use that on the command line, I get an administrative user back, but when I try it in the application, I get an invalid username/password error, like I should.
Could there be some sort of global PHP configuration they have enabled to block these attacks? Where would that be configured?
Here is the PHP --version information:
# php --version
PHP 5.2.12 (cli) (built: Feb 28 2010 15:59:21)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with the ionCube PHP Loader v3.3.14, Copyright (c) 2002-2010, by ionCube Ltd., and
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我的猜测是,您通过应用程序进行的尝试受到魔法引号的阻碍。
然而,依赖这种做法是极其糟糕的做法,该应用程序确实应该有更多自己的验证和转义。
My guess is that your attempts via the application are being thwarted by magic quotes.
Relying on such, however, is extremely bad practice, and that app really should have far more of its own verification and escaping.
在这个问题中你能做的就是你必须对数据进行良好的验证,并且对于每个非安全字符,如“你必须在它之前添加反斜杠,如下所示:\”并阻止获取 /* (这是使用 mysql 注释在sql注入中注释注入后的下一个sql语句。
All what you can do in this problem, is you must have a good validation of data, and for every non secure character as ' you must add backslash before it like that: \' and block to get /* (this is mysql comment using in sql injection for comment next sql statments after injection.
如果您在服务器上回显 $_POST['loginEmail'] 并尝试攻击,您很可能会看到 magic_quotes 已打开。
如果它被打开,它将看起来像 \' OR \'x\' = \'x
您应该使用 PDO 类 (http://www.php.net/manual/en/pdo.prepare.php)在您的所有 SQL 查询上。
If you echo out $_POST['loginEmail'] on your server and try the attack you will most likely see that magic_quotes is turned on.
If it is turned on it will look something like \' OR \'x\' = \'x
You should use the PDO class (http://www.php.net/manual/en/pdo.prepare.php) on all your SQL querys.
您在评论中提到,您试图确定是否启用了魔术引号:
您可能打算这样做:
最有可能的情况似乎是,正如其他人所说,魔术引号已打开。
You mentioned in a comment that you tried to determine if magic quotes were enabled with:
You probably meant to do this instead:
The most likely situation does seem to be, as others have said, that magic quotes are turned on.