SQL注入？字符（45,120,49,45,81,45）答案

【问题标题】：SQL injection? CHAR(45,120,49,45,81,45)SQL注入？字符（45,120,49,45,81,45）
【发布时间】：2013-06-30 14:52:05
【问题描述】：

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

完整的请求字符串是：

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) -- /*

编辑：由于谷歌搜索没有返回任何有用的信息，我想向遇到相同情况的人提问。

【问题讨论】：

有趣的是，现在这是我在 google 中进行的原始搜索的第二个结果。
甚至是第一！ ;-)

标签： sql-injection

【解决方案1】：

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

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

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

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

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

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

【讨论】：

很好的注入介绍，但并没有真正回答问题，即“那个特定的 SQL 试图实现什么？”
我对他们试图执行的特定 SQL 以及它如何工作都很感兴趣。由于谷歌搜索没有返回任何有用的信息，我想开始讨论可能处于危险中的人。
@roo，讨论并不是真正的 SO 目的。如果你说你想知道当前的攻击是如何工作的（这里似乎就是这种情况），那是另一回事。但开始讨论的愿望可能会导致问题被关闭和删除。
@paxdiablo - 公平点，讨论是错误的词。我提出这个问题是因为我不知道这个查询想要做什么，而谷歌也没有答案。我知道 SO 是获得答案的最佳场所，并且如果它是重要的事情，它的影响力最大。

【解决方案2】：

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

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

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

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

【讨论】：

“开发人员不应该关注任何注入机制、格式或含义——这些不关他的事。” - 你能详细说明吗？对我来说，这听起来像是我根本不应该关心 SQL 注入。或者将我所有的信任放在我使用的任何框架中。
是的，是的。就是这样 - 你不应该这样做。
太疯狂了！如果建议人们这样想，那你为什么写github.com/colshrapnel/safemysql？
这个库的真正目的确实是正确的格式。虽然提到的“安全”有更广泛的含义——查询是安全的，不会因格式不正确的文字（包括注入但不是针对）引起的任何错误。
嗯，好吧 - 所以你的意思是检查你的查询是否正确，而不关心利用它们的机制。这是有道理的。