报错型sql注入原理分析

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介:



0x00:前言

  关于sql注入,经久不衰,现在的网站一般对sql注入的防护也相对加强了,2016年的渗透测试报告中,出现最多的是xss(跨站脚本攻击)和明文传输等,但是对sql注入的利用方式,也相对成熟,详细了解sql注入,可以参考之前的文章。http://wt7315.blog.51cto.com/10319657/1828167


  今天主要分享下sql注入中的报错型,在大多网上的文章会列出类似于公式的句子,却没解释为什么要使用这样的函数,为什么使用这个函数会出现报错而导致sql注入。

wKiom1h3ItWCTQzdAAEIxiBGIp0244.png


0x01:报错过程


  我们先来了解几个函数。


   1. rand()用于产生一个0~1的随机数。

wKiom1h3JTXhL4YAAAEdGwL3xGo185.png


     2.floor()向下取整

wKiom1h3JZLDGOMbAAETUluF-18519.png



3. rand()函数生成0~1的函数,使用floor函数向下取整,值是固定的“0”,我们将rand*2,得到的值就是不固定的,“0”或者“1”。

wKioL1h3Jkby1UUaAAFNofyoZFY243.png



4.我们再来查询下当前的数据库,我使用的是“dvwa”数据库

wKiom1h3JoricrKzAAFCT92ad6M770.png




5.concat()将符合条件的同一列中的不同行数据拼接,为了待会便于观察,在此插入0x3a,0x3a是十六进制的“:”。

wKiom1h3J7iw3wqSAAD05Bs-Q3A875.png


 6. 将之前的rand()函数和floor()函数整合起来。

wKioL1h3KK3gHwl0AAD9ahXqDOE328.png


7.查询名字太长,我们来起个别名。

wKiom1h3KQPQDWHnAADnuukatnk104.png



8.我们再一次进行查询,information_schema.tables有多少个表哥,会显示多少列。

wKioL1h3KXzxHs8pAAYo87U4sZo273.png



9.group by 依据我们想要的规矩对结果进行分组。

wKiom1h3KeLAyxmCAAMsh1ER04o732.png

  10. count() 统计元祖的个数(相当于求和)。wKiom1h3Kq-Sn4hlAALwASocUA8158.png


11.接着,我们多重复几次。

wKiom1h3KubyQFI2AAF7LjL7vjQ229.png




0x02:

    rand()和rand(0)

1.加上随机因子后,执行多次每次都会报错。为了更彻底的说明报错原因,直接把随机因子去掉,再来一遍看看。


wKiom1h3K-eRb4XlAAASfr5gen0306.png


2.先看一条记录的时候,一条记录的话 无论执行多少次也不报错


wKioL1h3LF_xpDQLAACYXdpGuXg988.png


3.然后增加一条记录,两条记录的话 结果就变成不确定性了

wKioL1h3LJ2iyI2mAAAe8cEg64A201.png

wKiom1h3LJ3DLAu8AAAPlDhrv8w599.jpg

wKioL1h3LJ2RiGGmAAARMW23XGc056.jpg

随机出现报错,然后再插入一条,三条记录之后,也和2条记录一样进行随机报错。由此可见报错和随机因子是有关联的

0x03:不确定性与确定性

floor(rand(0)*2)报错的原理是恰恰是由于它的确定性,因为floor(rand()*2)不加随机因子的时候是随机出错的,而在3条记录以上用floor(rand(0)*2)就一定报错,由此可猜想floor(rand()*2)是比较随机的,不具备确定性因素,而floor(rand(0)*2)具备某方面的确定性。


我们分别对floor(rand()*2)和floor(rand(0)*2)在多记录表中执行多次。

wKioL1h3L3_idCVjAAAdzNW1ciY412.png


wKiom1h3L3_S5eyMAAAcR4ms5ms991.png


可以看到,floor(rand()*2)毫无规律可言,而floor(rand(0)*2)是有规律的。

那么mysql在遇到select count(*) from tables group by x;这语句的时候会建立一个虚拟表(实际上就是会建立虚拟表),整个工作流程就会如下图所示:


1.先建立虚拟表,如下图(其中key是主键,不可重复)

wKioL1h3McWSSPvxAAAx89I9UQ0466.png

2.开始查询数据,取数据库数据,然后查看虚拟表存在不,不存在则插入新记录,存在则count(*)字段直接加

wKioL1h3MkSisR50AAVyozP7cGs919.png


由此看到 如果key存在的话就+1, 不存在的话就新建一个key。


其实mysql官方有给过提示,就是查询的时候如果使用rand()的话,该值会被计算多次,那这个“被计算多次”到底是什么意思,就是在使用group by的时候,floor(rand(0)*2)会被执行一次,如果虚表不存在记录,插入虚表的时候会再被执行一次,我们来看下floor(rand(0)*2)报错的过程就知道了,从0x04可以看到在一次多记录的查询过程中floor(rand(0)*2)的值是定性的,为011011…(记住这个顺序很重要),报错实际上就是floor(rand(0)*2)被计算多次导致的。


我们做下整理。

1.查询前默认会建立空虚拟表。

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


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


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


整个查询过程floor(rand(0)*2)被计算了5次,查询原数据表3次,所以这就是为什么数据表中需要3条数据,使用该语句才会报错的原因。


0x04:loor(rand()*2)报错

由于没加入随机因子,所以floor(rand()*2)是不可测的,因此在两条数据的时候,只要出现下面情况,即可报错

wKiom1h3M8OQmRXkAAHG66caXS8278.png


前面几条记录查询后不能让虚表存在0,1键值,如果存在了,那无论多少条记录,也都没办法报错,因为floor(rand()*2)不会再被计算做为虚表的键值,这也就是为什么不加随机因子有时候会报错,有时候不会报错的原因。


0x05:updatexml报错


MySQL 5.1.5版本中添加了对XML文档进行查询和修改的函数,分别是ExtractValue()UpdateXML()


我们要学习的便是mysql里的修改函数即updatexml函数


其实也有extractvalue注入  以后的文章再做介绍。


先来做如下操作:


wKioL1h3NBTy-OODAAAjogv7ExE499.png


执行一下报错payload


and updatexml(1,concat(null,(select @@version),null),1);

wKioL1h3NDjjouEcAAAcThl3P2s639.png

updatexml的爆错原因很简单,updatexml第二个参数需要的是Xpath格式的字符串。我们输入的显然不符合。故报错由此报错。


updatexml的最大长度是32位的,所以有所局限(PS:但是应对大多的已经足够。)如果密码长度超过了32位就不会被显示出来。



0x06:其余报错函数

extractvalue() id = 1 and (extractvalue(1, concat(0x5c,(selectuser()))))

wKiom1h3Nt7C-m-LAAATeQKRA5w974.png


exp() id =1 and EXP(~(SELECT * from(select user())a))

wKioL1h3NwuhoZJhAAAXw7OsI-k873.png

这六个函数总的来说归于一类

GeometryCollection()
id = 1 AND GeometryCollection((select * from (select * from(select user())a)b))

polygon()
id =1 AND polygon((select * from(select * from(select user())a)b))

multipoint()
id = 1 AND multipoint((select * from(select * from(select user())a)b))

multilinestring()
id = 1 AND multilinestring((select * from(select * from(select user())a)b))

linestring()
id = 1 AND LINESTRING((select * from(select * from(select user())a)b))

multipolygon()
id =1 AND multipolygon((select * from(select * from(select user())a)b))


wKiom1h3Ny7xD_TUAACbked9bmA328.png


基于篇幅问题,剩下就不解释原理了,有机会,后面还会详细的介绍。



本文转自 wt7315 51CTO博客,原文链接:http://blog.51cto.com/wt7315/1891458

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
28天前
|
SQL 关系型数据库 MySQL
这样的SQL执行为什么不会报错?optimizer_trace深度历险
【10月更文挑战第12天】本文探讨了一条看似错误但实际上能成功执行的SQL语句,通过开启MySQL的优化器追踪功能,详细分析了SQL的执行过程,揭示了子查询被优化器解析为连接操作的原因,最终解释了为何该SQL不会报错。文章不仅增进了对SQL优化机制的理解,也展示了如何利用优化器追踪解决实际问题。
|
2月前
|
SQL 数据库
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
SQL Server附加数据库出现错误823,附加数据库失败。数据库没有备份,无法通过备份恢复数据库。 SQL Server数据库出现823错误的可能原因有:数据库物理页面损坏、数据库物理页面校验值损坏导致无法识别该页面、断电或者文件系统问题导致页面丢失。
101 12
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
|
2月前
|
SQL 数据库
SQL解析相关报错
SQL解析相关报错
45 5
|
1月前
|
SQL 关系型数据库 MySQL
|
1月前
|
SQL 存储 数据可视化
手机短信SQL分析技巧与方法
在手机短信应用中,SQL分析扮演着至关重要的角色
|
1月前
|
SQL 关系型数据库 数据库
SQL数据库:核心原理与应用实践
随着信息技术的飞速发展,数据库管理系统已成为各类组织和企业中不可或缺的核心组件。在众多数据库管理系统中,SQL(结构化查询语言)数据库以其强大的数据管理能力和灵活性,广泛应用于各类业务场景。本文将深入探讨SQL数据库的基本原理、核心特性以及实际应用。一、SQL数据库概述SQL数据库是一种关系型数据库
54 5
|
1月前
|
SQL 监控 安全
SQL注入公鸡分类及原理
SQL注入公鸡分类及原理
|
1月前
|
SQL 关系型数据库 MySQL
sql注入原理与实战(三)数据库操作
sql注入原理与实战(三)数据库操作
sql注入原理与实战(三)数据库操作
|
2月前
|
关系型数据库 MySQL Nacos
nacos启动报错 load derby-schema.sql error
这篇文章描述了作者在使用Nacos时遇到的启动错误,错误提示为加载derby-schema.sql失败,作者通过将数据库从Derby更换为MySQL解决了问题。
nacos启动报错 load derby-schema.sql error
|
2月前
|
SQL 安全 数据库
惊!Python Web安全黑洞大曝光:SQL注入、XSS、CSRF,你中招了吗?
在数字化时代,Web应用的安全性至关重要。许多Python开发者在追求功能时,常忽视SQL注入、XSS和CSRF等安全威胁。本文将深入剖析这些风险并提供最佳实践:使用参数化查询预防SQL注入;通过HTML转义阻止XSS攻击;在表单中加入CSRF令牌增强安全性。遵循这些方法,可有效提升Web应用的安全防护水平,保护用户数据与隐私。安全需持续关注与改进,每个细节都至关重要。
128 5

热门文章

最新文章