我刚刚在我们的请求日志中看到了这一点。他们想要达到什么目的?
完整的请求字符串为:
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) -- /*
编辑:由于谷歌搜索没有返回任何有用的东西,我想向遇到同样问题的人提出这个问题。
发布于 2013-07-03 11:24:54
Char()
函数将每个值解释为一个整数,并根据这些整数的代码值给定的字符返回一个字符串。使用Char()
时,将跳过空值。该函数在Microsoft SQL Server、Sybase和MySQL中使用,而CHR()
由RDBMS使用。
例如,当在SQL查询中使用addslashes()
for PHP作为预防措施时,SQL的Char()
函数就派上用场了。使用Char()
消除了在注入的查询中使用引号的需要。
使用Char()
的一些易受SQL注入攻击的PHP代码示例如下:
$uname = addslashes( $_GET['id'] );
$query = 'SELECT username FROM users WHERE id = ' . $id;
虽然使用了addslashes()
,但脚本无法正确清理输入,因为没有尾随的引号。可以使用以下SQL注入字符串加载/etc/passwd
文件来利用此漏洞:
https://stackoverflow.com/questions/17439121
复制相似问题