最近在折腾 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)) {
// 成功查询之后的处理. 略...
}
}
?>
<html><head><title>sample test</title></head>
<body>
<form method="post" action="">
Username: <input type="text" name="f_uname" size=30><br>
Password: <input type=text name="f_pwd" size=30><br> <input type="submit" name="f_login" value="登录">
</form>
</body>

在这个脚本中,当用户输入正常的用户名和密码,假设值分别为 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)) {
// 成功查询之后的处理. 略...
}
}
?>
<html><head><title>sample test</title></head>
<body>
<form method="post" action="">
User ID: <input type="text" name="f_uid" size=30><br>
Password: <input type=text name="f_pwd" size=30><br>
<input type="submit" name="f_login" value="登录">
</form>
</body>
</html>

上面这段脚本要求用户输入 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 注入攻击?我认为最重要的一点,就是要对数据类型进行检查和转义。总结的几点规则如下:

1. php.ini 中的 display_errors 选项,应该设为 display_errors = off。这样 php 脚本出错之后,不会在 web 页面输出错误,以免让攻击者分析出有作的信息。

2. 调用 mysql_query 等 mysql 函数时,前面应该加上 @,即 @mysql_query(...),这样 mysql 错误不会被输出。同理以免让攻击者分析出有用的信息。另外,有些程序员在做开发时,当 mysql_query出错时,习惯输出错误以及 sql 语句,例如:

$t_strSQL = "SELECT a from b....";
if (mysql_query($t_strSQL)) {
// 正确的处理
} else {
echo "错误! SQL 语句:$t_strSQL
错误信息" . mysql_query();
exit;
}

这种做法是相当危险和愚蠢的。如果一定要这么做,最好在网站的配置文件中,设一个全局变量或定义一个宏,设一下 debug 标志:

//全局配置文件中:
define("DEBUG_MODE", 0); // 1: DEBUG MODE; 0: RELEASE MODE //调用脚本中:
$t_strSQL = "SELECT a from b....";
if (mysql_query($t_strSQL)) {
// 正确的处理
} else {
if (DEBUG_MODE) {
echo "错误! SQL 语句:$t_strSQL
错误信息" . mysql_query();
}
exit;
}

3. 对提交的 sql 语句,进行转义和类型检查

四、我写的一个安全参数获取函数

为了防止用户的错误数据和 php + mysql 注入 ,我写了一个函数 PAPI_GetSafeParam(),用来获取安全的参数值:

define("XH_PARAM_INT", 0);
define("XH_PARAM_TXT", 1);
function PAPI_GetSafeParam($pi_strName, $pi_Def = "", $pi_iType = XH_PARAM_TXT) {
if (isset($_GET[$pi_strName])) {
$t_Val = trim($_GET[$pi_strName]);
} else if (isset($_POST[$pi_strName])) {
$t_Val = trim($_POST[$pi_strName]);
} else {
return $pi_Def;
} // INT
if (XH_PARAM_INT == $pi_iType) {
if (is_numeric($t_Val)) {
return $t_Val;
} else {
return $pi_Def;
}
} // String
$t_Val = str_replace("&", "&amp;", $t_Val);
$t_Val = str_replace("<", "&lt;", $t_Val);
$t_Val = str_replace(">", "&gt;", $t_Val); if (get_magic_quotes_gpc()) {
$t_Val = str_replace("\"", "&quot;", $t_Val);
$t_Val = str_replace("\''", "'", $t_Val);
} else {
$t_Val = str_replace(""", "&quot;", $t_Val);
$t_Val = str_replace("'", "'", $t_Val);
} return $t_Val;
}

在这个函数中,有三个参数:

  • $pi_strName:变量名
  • $pi_Def:默认值
  • $pi_iType: 数据类型。取值为 XH_PARAM_INT,XH_PARAM_TXT,分别表示数值型和文本型。

如果请求是数值型,那么调用 is_numeric() 判断是否为数值。如果不是,则返回程序指定的默认值。

简单起见,对于文本串,我将用户输入的所有危险字符(包括HTML代码),全部转义。由于 php 函数 addslashes()存在漏洞,我用 str_replace()直接替换。get_magic_quotes_gpc( ) 函数是 php 的函数,用来判断 magic_quotes_gpc 选项是否打开。

刚才第二节的示例,代码可以这样调用:

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

这样的话,就已经相当安全了。PAPI_GetSafeParam的代码有点长,但牺牲这点效率,对保证安全,是值得的。希望大家多批评指正。

注意:此篇文章原作者写于2007-03-14,原文地址:http://www.xiaohui.com/weekly/20070314.htm

PHP的SQL注入攻击的技术实现以及预防措施的更多相关文章

  1. 【web渗透技术】渗透攻防Web篇-SQL注入攻击初级

    [web渗透技术]渗透攻防Web篇-SQL注入攻击初级 前言不管用什么语言编写的Web应用,它们都用一个共同点,具有交互性并且多数是数据库驱动.在网络中,数据库驱动的Web应用随处可见,由此而存在的S ...

  2. 2017-2018-2 20179205《网络攻防技术与实践》第十一周作业 SQL注入攻击与实践

    <网络攻防技术与实践>第十一周作业 SQL注入攻击与实践 1.研究缓冲区溢出的原理,至少针对两种数据库进行差异化研究 缓冲区溢出原理   在计算机内部,输入数据通常被存放在一个临时空间内, ...

  3. 实例讲解 SQL 注入攻击

    这是一篇讲解SQL注入的实例文章,一步一步跟着作者脚步探索如何注入成功,展现了一次完整的渗透流程,值得一读.翻译水平有限,见谅! 一位客户让我们针对只有他们企业员工和顾客能使用的企业内网进行渗透测试. ...

  4. 防止SQL注入攻击的一些方法小结

    SQL注入攻击的危害性很大.在讲解其防止办法之前,数据库管理员有必要先了解一下其攻击的原理.这有利于管理员采取有针对性的防治措施. 一. SQL注入攻击的简单示例. statement := &quo ...

  5. SQL注入攻击和防御

    部分整理...   什么是SQL注入? 简单的例子, 对于一个购物网站,可以允许搜索,price小于某值的商品 这个值用户是可以输入的,比如,100 但是对于用户,如果输入,100' OR '1'=' ...

  6. SQL注入攻击

    SQL注入攻击是黑客对数据库进行攻击的常用手段之一.随着B/S模式应用开发的发展,使用这种模式编写应用程序的程序员也越来越多.但是由于程序员的水平及经验也参差不齐,相当大一部分程序员在编写代码的时候, ...

  7. SQL注入攻击的种类和防范手段

    观察近来的一些安全事件及其后果,安全专家们已经得到一个结论,这些威胁主要是通过SQL注入造成的.虽然前面有许多文章讨论了SQL注入,但今天所讨论的内容也许可帮助你检查自己的服务器,并采取相应防范措施. ...

  8. php安全编程—sql注入攻击

    php安全编程--sql注入攻击 定义 SQL注入攻击指的是通过构建特殊的输入作为参数传入Web应用程序,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因 ...

  9. php过滤提交数据 防止sql注入攻击

    规则 1:绝不要信任外部数据或输入 关于 Web 应用程序安全性,必须认识到的第一件事是不应该信任外部数据.外部数据(outside data) 包括不是由程序员在 PHP 代码中直接输入的任何数据. ...

随机推荐

  1. mui slider 改变默认index

    mui('class').slider().gotoItem(1,0) 目前已知问题,在class类名对应的dom元素是隐藏的时候初始化设置将报错,因为:  如果display取值是none,也就是不 ...

  2. C++读取特定路径下文件目录及文件名称

    这几天在弄一个项目,需要读取给定路径下的所有文件夹名称或所有带后缀的文件名. 查了下C++的资料,发现有很多方法,这里总结其中的一种,其他用法类似. 主要用到了以下几个头文件(类):io.h, fst ...

  3. document.cookie打不出来cookies

    比如session这种设置,都是设置了HttpOnly 导致document.cookie看不到,这和xss  跨站脚本攻击(Cross Site Scripting)

  4. Intelli IDEA 14.04开发版+注册码

    Idea,一款比较出色的IDE开发工具,懂她的人,自然懂得. 本版本-14.04+注册码 注册界面  注册码:               Name:happy                KEY: ...

  5. jQuery Mobile学习日记(二)

    首先依HTML5方式加载,DOCTYPE表示格式为HTML5:主要适用于iPhone.Android等,viewport表示适用于移动终端的适中显示,initial-scale缩放比例在1.0~1.3 ...

  6. Android的开发环境的发展演变

    1.Android的开发环境: 之前大家都是安装eclipse,然后再下载安装sdk等插件,还需要配置比较麻烦.不过2013年,有了新的选择,在I/O大会上,谷歌推出新的Android开发环境——An ...

  7. HashMap 和 HashTable区别

    HashMap 非线程安全的 HashTable线程安全的 package Collections.Map; import java.util.HashMap; public class HashMa ...

  8. BZOJ-1206 虚拟内存 Hash+离散化+Priority_Queue

    闻说HNOI每年都有一道Hash. 1206: [HNOI2005]虚拟内存 Time Limit: 50 Sec Memory Limit: 162 MB Submit: 330 Solved: 2 ...

  9. POJ3579 Median

    Description Given N numbers, X1, X2, ... , XN, let us calculate the difference of every pair of numb ...

  10. POJ1011 Sticks

    Description George took sticks of the same length and cut them randomly until all parts became at mo ...