Level1文章内容
前言
由于你之前偷看数据库时被其他管理员发现了,于是在被老板叫到办公室臭骂一顿后愤而辞职,到了另一个网站当管理员。非常不幸地是,在这个网站中你的权限也非常低,跟在之前网站的时候没啥区别,那叫一个气人啊。于是在一个月黑风高的晚上,你准备好好招待招待这个数据库。
题目分析
level2如下:
你轻车熟路地输入一个’后,发现跟之前的没啥区别嘛:
对于这个报错你也没多想,直接就开始 order by查询字段,但却发生了意想不到的事情:
天哪,竟然报错了!为什么会这样呢,这招明明在之前还行得通的呀,到底哪里出问题了?你盯着这个报错陷入了沉思。恍然间,你似乎发现了什么:
之前报错的是:1’
现在报错的是:’ 和 ‘order by 1,’
第一次报错跟第二次报错的区别就在于无把这个 1 显示出来。那为什么会产生这种差异呢,这种差异为什么会导致同样的order by查询语句结果却截然不同呢?
对比
关键点还是在“id”这个参数上。像PHP这种弱语言,“1”既可以是整型,也可以是字符型。如果id的参数类型为字符型,则实际上的SQL语句为(当前只考虑加了一对 ‘’ 的字符型参数):
……id='用户输入参数’
也就是说会自动加上一对单引号变为字符型;
如果id的参数类型为整型,则实际的SQL语句为:
……id=用户输入参数
而此时是没有加上一对单引号的。
漏洞划分
而由此产生的SQL注入漏洞就可以分为整型注入漏洞和字符型注入漏洞。
那要怎么判断到底是字符型漏洞还是整型漏洞呢?利用单引号报错虽然是个不错的办法,但万一没有把错误展示出来呢?所以比较常用的就是逻辑判断。方法如下:
若为整型:
输入 and 1=1 后与原先界面一致,而输入 and 1=2 之后页面显示不一致则为整型注入漏洞;
实际语句如下:……id=参数 and 1=1 或 ……id =参数 and 1=2
若为字符型:
输入 'and ‘1’=‘1 后与原先界面一致,而输入 'and ‘1’='2 之后页面显示不一致则为字符型注入;
实际语句如下:……id=’参数‘ and ’1‘ = ’2‘ 或 ……id=’参数‘ and ‘1’=‘2’
实际操作
因此如果在字符型漏洞中写入SQL语句时没有加上一对 ’‘ (笔者在level1中展示的语句中没有加上一对单引号,但在地址栏中确实是有加上,只是可恶的转码问题……),则实际的SQL语句为:
……id=’参数SQL语句‘
这就导致了我们写入的SQL语句根本没有被执行。
如果在整型漏洞中写入的SQL语句中加上一对 ’‘或者 , ,由于接收的参数为整型,所以会直接报错。
(一直要考虑这种单引号真的很麻烦地说,其实是可以通过注释的方式来避免的,具体有关闭合和注释的内容笔者将在Level3中详细阐述。)
以下是直接在level2中直接输入 order by 1 ,不输入一对单引号和句末逗号:
之后的操作与level1中一致,在此不做赘述。
总结
注入漏洞到底是字符型还是整型时可通过and语句的执行结果来进行判断;在面对整型和字符型漏洞时应对写入的SQL语句做微量的修改。
以上就是本篇的全部内容,我们下篇见。