求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
初探PHP的SQL注入攻击的技术实现以及预防措施
 
火龙果软件    发布于 2014-04-16
 

SQL攻击(SQL injection,台湾称作SQL资料隐码攻击),简称注入攻击,是发生于应用程序之数据库层的安全漏洞。简而言之,是在输入的字符串之中注入SQL指令,在设计不良的程序当中忽略了检查,那么这些注入进去的指令就会被数据库服务器误认为是正常的SQL指令而运行,因此遭到破坏。

有部份人认为SQL注入攻击是只针对Microsoft SQL Server而来,但只要是支持批处理SQL指令的数据库服务器,都有可能受到此种手法的攻击。

原因

在应用程序中若有下列状况,则可能应用程序正暴露在SQL Injection的高风险情况下:

在应用程序中使用字符串联结方式组合SQL指令。

在应用程序链接数据库时使用权限过大的账户(例如很多开发人员都喜欢用sa(内置的最高权限的系统管理员账户)连接Microsoft SQL Server数据库)。

在数据库中开放了不必要但权力过大的功能(例如在Microsoft SQL Server数据库中的xp_cmdshell延伸预存程序或是OLE Automation预存程序等)

太过于信任用户所输入的数据,未限制输入的字符数,以及未对用户输入的数据做潜在指令的检查。

作用原理

SQL命令可查询、插入、更新、删除等,命令的串接。而以分号字符为不同命令的区别。(原本的作用是用于SubQuery或作为查询、插入、更新、删除……等的条件式)

SQL命令对于传入的字符串参数是用单引号字符所包起来。《但连续2个单引号字符,在SQL数据库中,则视为字符串中的一个单引号字符》

SQL命令中,可以注入注解《连续2个减号字符 -- 后的文字为注解,或“/*”与“*/”所包起来的文字为注解》

因此,如果在组合SQL的命令字符串时,未针对单引号字符作取代处理的话,将导致该字符变量在填入命令字符串时,被恶意窜改原本的SQL语法的作用。

最近翻到一本有关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>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 语句变成:

INSERT INTO tbl_user SET uid="1";
  SELECT * FROM tbl_user WHERE uid="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>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 语句,例如:

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

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

<?php
//全局配置文件中:
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(),用来获取安全的参数值:

<?php
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("&", "&", $t_Val);
$t_Val = str_replace("<", "<", $t_Val);
$t_Val = str_replace(">", ">", $t_Val);
if (get_magic_quotes_gpc()) {
$t_Val = str_replace("\"", """, $t_Val);
$t_Val = str_replace("\''", "'", $t_Val);
} else {
$t_Val = str_replace(""", """, $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 选项是否打开。
  刚才第二节的示例,代码可以这样调用:

<?php
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的代码有点长,但牺牲这点效率,对保证安全,是值得的。希望大家多批评指正。

 
相关文章

iOS应用安全开发,你不知道的那些事术
Web安全之SQL注入攻击
移动APP安全在渗透测试中的应用
从Google备份互联网看“数据安全”
 
相关文档

web安全设计与防护
互联网海量内容安全处理技术
黑客攻击与防范技术
WEB黑盒安全检测
 
相关课程

WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
信息安全问题与防范
 
分享到
 
 


iOS应用安全开发
Web安全之SQL注入攻击
APP安全在渗透测试中的应用
初探PHP的SQL注入攻击的技术
从Google备份看“数据安全”
更多...   


WEB网站与应用安全原理与实践
web应用安全架构设计
创建安全的J2EE Web应用代码
注册信息安全专业人员(CISP)
信息安全管理
信息安全问题与防范


中国银行 信息安全技术及深度防御
Web应用安全架构、入侵检测与防护
某财税领域知名IT服务商 Web安全测试
普瑞克斯 web安全设计、测试与优化
北京和利时 性能和安全性测试
SUN中国工程研究院 JSF框架、安全
更多...