[转载]SQL注入攻击之 mysql_set_charset(版本要求p

原文地址：SQL注入攻击之 mysql_set_charset(版本要求php>=5.2.3/mysqli>=5.0.7) 作者：HELLO_FRANCA

SQL注入攻击之 mysql_set_charset

mysql_set_charset

(PHP 5 >= 5.2.3)

mysql_set_charset ― Sets the client character set

说明

bool mysql_set_charset ( string $charset [, resource $link_identifier ] )

Sets the default character set for the current connection.

参数

 

charset

A valid character set name.

link_identifier

MySQL 连接。如不指定连接标识，则使用由 mysql_connect() 最近打开的连接。如果没有找到该连接，会尝试不带参数调用 mysql_connect() 来创建。如没有找到连接或无法建立连接，则会生成 E_WARNING 级别的错误。

返回值

成功时返回 TRUE， 或者在失败时返回 FALSE.

注释

Note:

This function requires MySQL 5.0.7 or later.

Note:

This is the preferred way to change the charset. Using mysql_query() to execute SET NAMES .. is not recommended.

1。老话题，mysql_real_escape_string+单引号，大多数情况下，防止sql注入攻击足够了。

$mysql = mysql_connect("host","user","passwort");

$value = mysql_real_escape_string($value,$mysql);

$sql = "select * from table where col = '$value' ";

mysql_query($sql,$mysql);

2。但是我的数据库是gbk的，我需要使用gbk去连接数据库，我使用set names gbk来告诉服务器我要如何使用编码。

$mysql = mysql_connect("host","user","passwort");

$sql = "set names gbk";

mysql_query($sql,$mysql);

$value = mysql_real_escape_string($value,$mysql);

$sql = "select * from table where col = '$value' ";

mysql_query($sql,$mysql);

3。但是中途使用"set names gbk" 修改了字符集，mysql_real_escape_string函数不会相应的更新字符集。因为set names gbk只是告诉了服务器我要做什么，php的mysql客户端不知道发生了什么，所以mysql_connection认为自己的字符集没有发生变化，这时候使用mysql_client_encoding获取的还是之前的编码。

$mysql = mysql_connect("host","user","passwort");

$encoding = mysql_client_encoding($mysql) ;   // => latin1

$sql = "set names gbk";

mysql_query($sql,$mysql);

$encoding = mysql_client_encoding($mysql) ;   // => latin1

$value = mysql_real_escape_string($value,$mysql);

$sql = "select * from table where col = '$value' ";

mysql_query($sql,$mysql);

4。在这种情况下，mysql_real_escape_string使用latin1来转义输入参数，但是使用gbk来查询，就存在被SQL注入攻击的风险。

$value = chr(0xbf).chr(0x27)." or col is not null -- ";

$value = mysql_real_escape_string($value,$mysql);

=> $value = chr(0xbf).chr(0x5c).chr(0x27)." or col is not null -- ";

其中，chr(0xbf).chr(0x5f)组成汉字“俊保0x27就是单引号，被成功注入。

5。因此，需要告诉php，我修改字符集编码了。mysql_set_charset就做到了这一点。它其实更强大，把set names gbk这事一并作了。

mysql_set_charset("gbk",$mysql);

$value = chr(0xbf).chr(0x27)." or col is not null -- ";

$value = mysql_real_escape_string($value,$mysql);

=> $value =chr(0x5c).chr(0xbf).chr(0x5c).chr(0x27)." or col is not null -- ";

注意加粗的地方，也就是第一个chr(0x5c)，因为0xbf不是合法的gbk字符，所以前面加了一个反斜杆将其转义。这样，0xbf就不能和0x5c组成汉字了，而是 (0x5c0xbf) (0x5c0x27)， SQL注入失败!!

6。很可惜，mysql_set_charset在php5.2.3之后才出现，你必须升级你的php版本了。

同时，也需要mysql的版本在5.0.7或之上，所以也要注意。

wget   && tar -xzvf && configure && make && make install

7。有时候，mysql_set_charset("gbk")失败了，返回结果为

$ret = mysql_set_charset("gbk",$mysql);

if($ret == false){

echo mysql_error();

}

=> Can't initialize character set GBK (path: /usr/local/share/mysql/charsets/)

8。悲剧阿！想办法吧。重新编译mysql，把gbk编译进去就行了

./configure --with-extra-charsets=gbk && make clean && make && make install

9。请记住，抛弃set names gbk吧，咱们用mysql_set_charset，安全，很重要。

PHP的手册上也这么讲，所以你还是别坚持了

This is the preferred way to change the charset. Using mysql_query() to execute SET NAMES .. is not recommended.

10。那么，为什么我一开始获得的client_charset是latin1而不是gbk呢？

$encoding = mysql_client_encoding($mysql) ;   // => latin1

登陆数据库，察看编码

mysql> show variables like '%set%';

| character_set_client     | latin1                     |

| character_set_connection | latin1                     |

| character_set_database   | latin1                     |

| character_set_filesystem | binary                     |

| character_set_results     | latin1                     |

| character_set_server     | latin1                     |

| character_set_system     | utf8                       |

可以看到，character_set_client为latin1，就是它，直接决定了mysql_client_encoding的返回结果。

set names gbk的结果，是同时对该连接修改上面的character_set_client、character_set_connectio、character_set_results 

mysql> set names gbk;

Query OK, 0 rows affected (0.00 sec)

mysql> show variables like '%set%';

+--------------------------+----------------------------+

| Variable_name             | Value                       |

+--------------------------+----------------------------+

| auto_increment_offset     | 1                           |

| character_set_client     | gbk                         |

| character_set_connection | gbk                         |

| character_set_database   | latin1                     |

| character_set_filesystem | binary                     |

| character_set_results     | gbk                         |

| character_set_server     | latin1                     |

| character_set_system     | utf8                       |

| character_sets_dir       | /usr/share/mysql/charsets/ |

+--------------------------+----------------------------+

9 rows in set (0.00 sec)

所以，我们很容易得出这个结论，只要中途没有使用set names gbk将原本非gbk的连接改成gbk的连接，mysql_real_escape_string就是安全的。如果原来也是gbk的，set names gbk没有任何效果，也不会对mysql_real_escape_string的安全造成威胁。

11。分析一下，导致mysql_real_escape_string存在风险的根源是什么呢？

产生风险的根源是单引号被注入；单引号被注入的根源是gbk中，0x27在身为单引号的同时，又是其它有效多字节文字的组成部分；而utf8中，0x00-0x7F都不是任何其它字符的组成部分，所以不存在被注入单引号的风险；所以，将一个其它字符集的MYSQL连接 SET NAME utf8，并不会带来额外的风险。

12。 结论：要避开mysql_real_escape_string可能的风险，有以下策略

1）数据库表使用的编码与数据库变量character_set_client指定的编码相同，这样不需要set names xxx来改变编码。

2）数据库表使用latin1或utf8等字符集，这样set names xxx也不会带来额外的风险。

3）当需要set names gbk时，使用mysql_set_charset来替代。