Home >php教程 >php手册 >PHP+SQL 注入攻击的技术实现以及预防办法

PHP+SQL 注入攻击的技术实现以及预防办法

WBOY
WBOYOriginal
2016-06-06 20:35:471103browse

最近在折腾 PHP + MYSQL 的编程。了解了一些 PHP SQL 注入攻击的知识,总结一下经验。在我看来,引发 SQL 注入攻击的主要原因,是因为以下两点原因

1. php 配置文件 php.ini 中的 magic_quotes_gpc 选项没有打开,被置为 off
2. 开发者没有对数据类型进行检查和转义
  不过事实上,第二点最为重要。我认为, 对用户输入的数据类型进行检查,向 MYSQL 提交正确的数据类型,这应该是一个 web 程序员最最基本的素质。但现实中,常常有许多小白式的 Web 开发者忘了这点, 从而导致后门大开。
  为什么说第二点最为重要?因为如果没有第二点的保证,magic_quotes_gpc 选项,不论为 on,还是为 off,都有可能引发 SQL 注入攻击。下面来看一下技术实现:
 一. magic_quotes_gpc = Off 时的注入攻击
  magic_quotes_gpc = Off 是 php 中一种非常不安全的选项。新版本的 php 已经将默认的值改为了 On。但仍有相当多的服务器的选项为 off。毕竟,再古董的服务器也是有人用的。
  当magic_quotes_gpc = On 时,它会将提交的变量中所有的 '(单引号)、"(双号号)、\(反斜线)、空白字符,都为在前面自动加上 \。下面是 php 的官方说明:

复制代码 代码如下:


magic_quotes_gpc boolean
Sets the magic_quotes state for GPC (Get/Post/Cookie) operations. When magic_quotes are on, all ' (single-quote), " (double quote), \ (backslash) and NUL's are escaped with a backslash automatically


如果没有转义,即 off 情况下,就会让攻击者有机可乘。以下列测试脚本为例:

复制代码 代码如下:



if ( isset($_POST["f_login"] ) )
{
// 连接数据库...
// ...代码略...

// 检查用户是否存在
$t_strUname = $_POST["f_uname"];
$t_strPwd = $_POST["f_pwd"];
$t_strSQL = "SELECT * FROM tbl_users WHERE username='$t_strUname' AND password = '$t_strPwd' LIMIT 0,1";

if ( $t_hRes = mysql_query($t_strSQL) )
{
// 成功查询之后的处理. 略...
}
}
?>

sample test


Username:

Password:






在这个脚本中,当用户输入正常的用户名和密码,假设值分别为 zhang3、abc123,则提交的 SQL 语句如下:

复制代码 代码如下:


SELECT * FROM tbl_users
WHERE username='zhang3' AND password = 'abc123' LIMIT 0,1


如果攻击者在 username 字段中输入:zhang3' OR 1=1 #,在 password 输入 abc123,则提交的 SQL 语句变成如下:

复制代码 代码如下:


SELECT * FROM tbl_users
WHERE username='zhang3' OR 1=1 #' AND password = 'abc123' LIMIT 0,1


由于 # 是 mysql中的注释符, #之后的语句不被执行,实现上这行语句就成了:

复制代码 代码如下:


SELECT * FROM tbl_users
WHERE username='zhang3' OR 1=1


这样攻击者就可以绕过认证了。如果攻击者知道数据库结构,那么它构建一个 UNION SELECT,那就更危险了:
  假设在 username 中输入:zhang3 ' OR 1 =1 UNION select cola, colb,cold FROM tbl_b #
  在password 输入: abc123,
  则提交的 SQL 语句变成:

复制代码 代码如下:


SELECT * FROM tbl_users
WHERE username='zhang3 '
OR 1 =1 UNION select cola, colb,cold FROM tbl_b #' AND password = 'abc123' LIMIT 0,1


这样就相当危险了。如果agic_quotes_gpc选项为 on,引号被转义,则上面攻击者构建的攻击语句就会变成这样,从而无法达到其目的:

复制代码 代码如下:


SELECT * FROM tbl_users
WHERE username='zhang3\' OR 1=1 #'
AND password = 'abc123'
LIMIT 0,1
SELECT * FROM tbl_users
WHERE username='zhang3 \' OR 1 =1 UNION select cola, colb,cold FROM tbl_b #'
AND password = 'abc123' LIMIT 0,1


二. magic_quotes_gpc = On 时的注入攻击
  当 magic_quotes_gpc = On 时,攻击者无法对字符型的字段进行 SQL 注入。这并不代表这就安全了。这时,可以通过数值型的字段进行SQL注入。
  在最新版的 MYSQL 5.x 中,已经严格了数据类型的输入,已默认关闭自动类型转换。数值型的字段,不能是引号标记的字符型。也就是说,假设 uid 是数值型的,在以前的 mysql 版本中,这样的语句是合法的:

复制代码 代码如下:


INSERT INTO tbl_user SET uid="1";
SELECT * FROM tbl_user WHERE uid="1";


在最新的 MYSQL 5.x 中,上面的语句不是合法的,必须写成这样:

复制代码 代码如下:


INSERT INTO tbl_user SET uid=1;
SELECT * FROM tbl_user WHERE uid=1;


这样我认为是正确的。因为作为开发者,向数据库提交正确的符合规则的数据类型,这是最基本的要求。
  那么攻击者在 magic_quotes_gpc = On 时,他们怎么攻击呢?很简单,就是对数值型的字段进行 SQL 注入。以下列的 php 脚本为例:

复制代码 代码如下:



if ( isset($_POST["f_login"] ) )
{
// 连接数据库...
// ...代码略...
// 检查用户是否存在
$t_strUid = $_POST["f_uid"];
$t_strPwd = $_POST["f_pwd"];
$t_strSQL = "SELECT * FROM tbl_users WHERE uid=$t_strUid AND password = '$t_strPwd' LIMIT 0,1";
if ( $t_hRes = mysql_query($t_strSQL) )
{
// 成功查询之后的处理. 略...
}
}
?>

sample test


User ID:

Password:





上面这段脚本要求用户输入 userid 和 password 登入。一个正常的语句,用户输入 1001和abc123,提交的 sql 语句如下:
SELECT * FROM tbl_users WHERE userid=1001 AND password = 'abc123' LIMIT 0,1
  如果攻击者在 userid 处,输入:1001 OR 1 =1 #,则注入的sql语句如下:
SELECT * FROM tbl_users WHERE userid=1001 OR 1 =1 # AND password = 'abc123' LIMIT 0,1
  攻击者达到了目的。
 三. 如何防止 PHP SQL 注入攻击
  如何防止 php sql 注入攻击?我认为最重要的一点,就是要对数据类型进行检查和转义。总结的几点规则如下:
php.ini 中的 display_errors 选项,应该设为 display_errors = off。这样 php 脚本出错之后,不会在 web 页面输出错误,以免让攻击者分析出有作的信息。
调用 mysql_query 等 mysql 函数时,前面应该加上 @,即 @mysql_query(...),这样 mysql 错误不会被输出。同理以免让攻击者分析出有用的信息。另外,有些程序员在做开发时,当 mysql_query出错时,习惯输出错误以及 sql 语句,例如:

复制代码 代码如下:

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn