35

我刚刚在我们的请求日志中看到了这一点。他们想达到什么目的？

完整的请求字符串是：

properties?page=2side1111111111111 UNION SELECT CHAR(45,120,49,45,81,45),CHAR(45,120,50,45,81,45),CHAR(45,120,51,45,81,45),CHAR(45,120,52,45,81,45),CHAR(45,120,53,45,81,45),CHAR(45,120,54,45,81,45),CHAR(45,120,55,45,81,45),CHAR(45,120,56,45,81,45),CHAR(45,120,57,45,81,45),CHAR(45,120,49,48,45,81,45),CHAR(45,120,49,49,45,81,45),CHAR(45,120,49,50,45,81,45),CHAR(45,120,49,51,45,81,45),CHAR(45,120,49,52,45,81,45),CHAR(45,120,49,53,45,81,45),CHAR(45,120,49,54,45,81,45) -- /*

编辑：由于谷歌搜索没有返回任何有用的信息，我想问遇到同样事情的人这个问题。

4

2 回答 2

22

这只是一个注入测试。如果攻击者可以在输出中看到 xQ，那么他们就会知道注入是可能的。

此特定查询没有“风险”。

开发人员不应该关注任何注入机制、格式或含义——这些不关他的事。

所有无限数量的注入只有一个原因 -格式不正确的查询。只要您的查询格式正确，就不可能进行 SQL 注入。专注于您的查询，而不是 SQL 注入的方法。

于 2013-07-03T04:33:10.210 回答
7

该Char()函数将每个值解释为一个整数，并根据这些整数的代码值给定的字符返回一个字符串。使用Char()时，会跳过 NULL 值。该函数在 Microsoft SQL Server、Sybase 和 MySQL 中使用，而CHR()由 RDBMS 使用。

Char()当（例如）addslashes()将 PHP 用作 SQL 查询中的预防措施时， SQL 的功能会派上用场。UsingChar()消除了注入查询中对引号的需求。

一些易受 SQL 注入攻击的 PHP 代码示例Char()如下所示：

$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;

虽然addslashes()已被使用，但脚本无法正确清理输入，因为没有尾随引号。/etc/passwd可以使用以下 SQL 注入字符串加载文件来利用这一点：

来源：http ://hakipedia.com/index.php/SQL_Injection#Char.28.29

于 2013-07-03T03:24:53.750 回答