到主键冲突：深入剖析floor()报错注入的底层机制)
1. 为什么floor()报错注入值得深入研究
第一次接触floor()报错注入时，很多人会觉得这不过是又一个SQL注入技巧罢了。但当我真正深入MySQL源码层面分析时，才发现这个看似简单的报错背后，隐藏着数据库引擎处理分组查询的精妙机制。这种注入方式之所以特殊，是因为它不像常规注入那样依赖明显的逻辑漏洞，而是巧妙地利用了数据库内部处理临时表时的边界条件。
记得去年在给公司做安全审计时，就遇到过一个真实案例。某电商平台的搜索接口存在SQL注入漏洞，但常规的union select和布尔盲注都被WAF拦截得死死的。最后正是靠着floor()报错注入，我们成功获取了数据库权限。当时团队里有个新人问我："为什么这个注入方式需要至少三条数据才会报错？"这个问题直接戳中了floor()注入最核心的机制。
2. 关键函数的工作原理剖析
2.1 rand()函数的确定性之谜
很多人以为rand()就是个简单的随机数生成器，但加上种子参数后，它的行为就变得非常有趣。在MySQL中，rand(0)会产生一个固定的伪随机序列。我做过实测，在5.7和8.0版本中，执行：
SELECT rand(0) FROM (SELECT 1 UNION SELECT 2 UNION SELECT 3) as t;得到的序列永远是0.15522042769493574, 0.620881741513388, 0.6387634553767775。这个特性正是floor()注入能够稳定复现的关键。如果没有指定种子，每次调用rand()都会产生真正的随机值，注入就会变得不可控。
2.2 floor()的数学魔法
floor()函数的行为很简单——向下取整。但配合rand(0)*2使用时，就产生了二进制开关的效果。来看个实际例子：
SELECT floor(0.15522042769493574 * 2); -- 返回0 SELECT floor(0.620881741513388 * 2); -- 返回1这个0和1的交替序列，将成为后续主键冲突的导火索。我在本地测试时发现，使用rand(0)产生的序列前五位是：0,1,1,0,1（对应floor计算后的结果）。这个特定序列恰好满足触发条件。
3. group by与临时表的幕后机制
3.1 虚拟表的创建过程
MySQL处理group by时，会在内存中创建一张虚拟临时表。这个机制我通过explain验证过，当执行包含group by的查询时，Extra字段会显示"Using temporary"。临时表的结构大致是这样的：
| group_key | count |
|---|---|
| (动态生成) | (累计值) |
关键点在于：当遇到新的group_key时，引擎会先检查临时表是否存在该键，如果不存在就插入。这个检查-插入的过程，正是漏洞触发的契机。
3.2 主键冲突的产生时机
让我们用实际数据推演整个过程。假设有张表test有三条记录，执行：
SELECT count(*), floor(rand(0)*2) as x FROM test GROUP BY x;MySQL的处理流程是这样的：
- 读取第一条记录，计算floor(rand(0)*2)=0（第一次计算）
- 检查临时表没有key=0的记录，准备插入
- 插入前重新计算floor(rand(0)*2)=1（第二次计算）
- 插入key=1，count=1
- 读取第二条记录，计算floor(rand(0)*2)=1（第三次计算）
- 发现key=1存在，直接count+1
- 读取第三条记录，计算floor(rand(0)*2)=0（第四次计算）
- 检查发现key=0不存在，准备插入
- 插入前计算floor(rand(0)*2)=1（第五次计算）
- 尝试插入key=1但已存在，触发主键冲突
这个流程解释了为什么最少需要三条数据——只有到第三条时才会满足"先查无key，插入时key又已存在"的条件。
4. 实战中的注意事项与变体
4.1 种子值的选择艺术
rand(0)中的0不是随便选的。我测试过不同种子：
- 种子0：稳定产生0,1,1,0,1序列
- 种子1：产生1,0,0,0,0序列（无法触发冲突）
- 种子2：产生0,1,1,1,1序列（同样无效）
这说明种子选择直接影响注入成功率。在实际渗透测试中，如果使用rand()不带种子，成功率可能只有50%左右。
4.2 表数据量的影响
有个容易误解的点：不是说表数据越多越好。关键是有足够记录让floor(rand(0)*2)计算达到冲突点。我做过实验：
- 3条记录：稳定触发
- 2条记录：从不触发
- 4条记录：仍然在第3条处理时触发
这是因为虚拟表是按行处理的，与总记录数无关，只与处理顺序有关。
4.3 现代防御措施绕过
现在很多WAF会检测floor(rand(0)*2)这种模式。我最近发现几个绕过技巧：
- 使用hex编码：floor(rand(0)*0x2)
- 变量替换：set @a=2; floor(rand(0)*@a)
- 嵌套表达式：floor(rand(0)*(1+1))
但这些方法都需要根据具体环境调整。在最近一次红队演练中，我们就用变量替换的方式成功绕过了某云WAF的检测。
5. 从原理到防御的思考
理解了注入原理后，防御策略就清晰了。除了常规的参数化查询外，我建议开发者在MySQL配置中：
- 设置sql_mode包含STRICT_ALL_TABLES
- 限制应用程序账户的权限，避免访问information_schema
- 对数据库错误信息进行统一处理，不直接返回给客户端
在代码审查时，要特别注意包含group by的动态SQL拼接。有次代码审计中，我就发现某框架的统计模块直接拼接了用户输入的排序字段，导致了潜在的注入风险。
