user_id条目时，我正在浏览数据库中的一些数据：我的一部分认为这可能是由某种错误引起的，但是再次看到在数据条目中包含SQL还是很可疑的。它会试图做什么？
以下是一些我发现可能很有趣的示例：
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#
#1 楼
看看“联合注入” SQL攻击，例如在这里找到的。基本上，它正在尝试各种方法来标识查询中的列数，寻找成功的列数。
order by行尝试检测由特定列排序的数据与尝试由不存在的列进行排序而导致的错误之间的差异，而select的行则试图使有效的UNION命令起作用-仅当两者在一个联合中合并的查询具有相同的列数。从某些行末尾的随机字母来看，很可能是有人针对您的表单运行了sqlmap工具，但是事实在数据库中找到它们是一件好事-这表明尝试失败了，尽管这些可能只是成功攻击的失败部分。
评论
除了这是更新还是插入语句，而不是选择语句。我们知道是因为我们在数据库中找到了user_id条目。 （当然，这并不是攻击者知道的-他可能只是将数据插入表单上的方便字段中）
–塔米尔
17年9月30日在7:17
有时，攻击者没有意识到特定入口点的多种副作用。例如他们可能会插入搜索框，期望它只会影响收到的结果，但是如果结果记录在某处，那么它们也可能会意外破坏“ INSERT”子句。并可能在管理员加载“日志”页面时导致错误（也是一种非常强大的攻击途径）
– JeffUK
17-10-2在13:30
好答案！我要补充一点，如果用户ID应该是数字的，那么您可以插入字符串的事实就不好了。本身并不危险，但有点草率。此外，用户是否真的可以选择自己的ID？而且，如果这不在用户表中，那么是否应该没有外键将限制值限制给现有用户？
–安德斯
17-10-3在7:30
#2 楼
这是某人试图利用您网站上的SQL注入的结果。有人试图检测您的网站是否容易受到基于联合的注入的攻击。对于您看到的所有记录，它似乎都没有用。 >我注意到的一件可疑的事情是，我看不到任何包含双引号（“）的条目，这可能表明它们破坏了网站的功能或使用双引号对您的网站进行注入。 br />
您可能想检查相关的源代码以查看是否对参数值进行了正确的清理，如果您的设置的其他部分用双引号或注入阻止了请求，也可以对此进行解释只是没有尝试。
评论
如果针对插入或更新语句，此攻击如何起作用？我试图将order by子句或联合插入到select语句中，但是结果对于插入似乎没有意义。我想工会可能会导致明显的时间差异进行更新。
–塔米尔
17年9月30日在7:20
我想如果攻击成功了，它将在实际字段中插入联合值。这些字段以后可以通过各种方式公开（例如，您可能使用用户名作为个人资料图片的url的一部分，或者可能引发错误“未知角色79”。攻击者知道这是可能的，然后可以更改查询以通过该字段公开关键信息（例如，第一个用户的密码哈希，或尝试对数据库用户的密码进行半盲法猜测。）如果他们可以通过sql。
– Sumurai8
17年9月30日9:00
看到我对这种情况的回答。它们存在，我已经看到了！
–mvds
17年9月30日在16:43
不存在双引号可能只是因为双引号仅用于标识符（如果有）。在SQL注入中使用它们没有任何意义。
–凯特
17-10-3在19:38
#3 楼
除了已经给出的良好答案（表明这些可能是尝试失败的迹象）之外，我还要补充一点，这些用户ID可能是更精细的成功注入的一部分。理论上的。我遇到过这样的情况：在第二个查询中使用一个选择查询的结果而没有正确的输入验证。开发人员可能只验证用户的直接输入，并且（错误地）假定来自数据库的任何信息都是安全的。直到存储这些用户ID值之前，没有什么错，但是在随后的查询中，魔术发生了。特别危险的是将整数字段转换为字符串，因为整数通常在不使用转义或引号的情况下使用。在未知系统上进行注入，而不会触发至少一些错误。除此之外，在生产系统中任何查询都不会失败（如：语法错误）。
评论
对从数据库读取的内容缺乏“适当的输入无效”不足以使人们陷入这种麻烦-还需要忽略基本规则，即永远不要通过字符串串联生成SQL查询。
–查尔斯·达菲（Charles Duffy）
17-10-1在15:12
@CharlesDuffy不允许通过字符串串联生成参数化查询吗？您将如何生成带有IN子句的参数化SQL查询，该IN子句的有效值数量会有所变化？
–亚历山大
17年10月2日，1：13
@Alexander如果它们都是常量，那就可以了。但是，如果任何地方都有变量，则没有。查询5000003个字符可能不是一个好主意。
– wizzwizz4
17-10-2在7:07
我看不出在这里进行讨论的意义。但是我想强调一点，如果您信任来自数据库的内容，那么“基本的SQL规则”将永远不会为您省钱。世界比SQL还要大：内容可以在其他各种（非参数化）上下文中使用，每种上下文都有自己的引用/转义要求。主要规则应该是不信任来自数据库的内容，并将其视为用户输入。
–mvds
17-10-2在7:55
这是一个很好的建议，多步攻击更恶性，但很少有人考虑。
–克里斯托弗·鲁西（Christophe Roussy）
17年10月2日，9：07
评论
根据定义，它是一个SQL注入。我假设user_id应该保留一个整数值，但不是。某些内容已将一些数据注入到不应包含在查询中的数据，因为它保存的是字符串，而不是整数。不要以为这是一个正确的假设-user_id列中包含GUID甚至是人们通常认为用户名的名称都是很常见的。没有足够的上下文可以在此处明确声明。
如果应该是GUID，为什么还要将它们存储为字符串？ PostgreSQL具有专用的UUID类型。另外，为什么您的应用程序不拒绝任何不采用众所周知的GUID / UUID格式的内容？似乎您在接受输入数据的验证代码中至少有错误。
这是尝试执行SQL注入。您有一些网站可以输入用户名和密码，有人输入了这些奇怪的用户名以尝试执行SQL注入。显然，您的网站不容易受到攻击，因此将这些奇怪的用户名记录为合法的用户名。从您的应用程序的角度来看，这绝对可以。如果我使用用户名“ -1080）ORDER BY 1＃”注册，则此功能在您的网站上可以正常使用。
有什么想法可以作为注释的随机字母（例如-vJzG）是什么？