[SWPU2019]Web1(二次注入,无列名注入,bypass information_schema)

0x00 知识点

二次注入流程分析

1. 二次注入漏洞在CTF中常见于留言板和注册登录功能,简单来说可以分为两个步骤:
   1. 插入恶意数据(发布帖子,注册账号),用mysql_escape_string()函数对恶意字符进行转义,但是再将数据写入数据库中的时候又保留了原来的数据.
   2. 引用插入的恶意数据:在进行查询时,直接从数据库中引用恶意数据,没有做进一步过滤和检验.

bypass information_schema

参考文章:https://www.anquanke.com/post/id/193512

1. information_schema这个数据库存放着其他数据库的信息,包括表名,字段名等.在常规注入过程中利用information_schema就是想要获取到其中的信息.
2. mysql在5.7版本中新增了sys.schema:
   1. sys.schema_auto_increment_columns #该视图的作用是对表自增ID进行监控就是说,某张表如果存在自增ID,我们就可以通过该视图获取数据库的该表名信息.
   2. 如果该表没有自增主键呢?->sys.schema_table_statistics_with_buffer
   3. payload(环境:sqli-labs Less1):
      1. ?id=-1‘ union select 1,(select group_concat(table_name) from sys.schema_auto_increment_columns where table_schema=database()),3 --+
      2. ?id=-1‘ union select 1,(select group_concat(table_name) from sys.schema_table_statistics_with_buffer where table_schema=database()),3 --+
   4. 限制条件:
      1. mysql version>=5.7
      2. 要求权限高,一般root用户才可以访问

无列名注入

1. 如果information_schema被WAF,得到表名之后使用无列名注入技巧获取字段值.
   

2. 之后就可以利用数字来对应相应的列,进行查询
   ?这里有两点需要注意一下:

   1. 列名需要用``包裹起来
   2. 使用子查询的时候,即一个查询嵌套在另一个查询中,内层查询的结果可以作为外层查询的条件,内层查询到的结果需要起一个别名(as)

3. 如果反引号``被过滤,可以使用为字段起别名的方式.
   

0x01 解题

1)留言板二次注入：我们申请广告的时候数据库将我们输入的恶意字符进行转义，但是写入数据库的时候会将数据还原。当点击查看广告详情的时候数据库对查询到的结果并未严格过滤，导致了二次注入。
2)题目过滤了空格，or，注释符号，导致了order by,information_schema都被WAF.绕过姿势:空格用内联注释绕过，or用异或^绕过，最后考虑闭合单引号的问题。
3)这道题目在buuoj上的复现是没办法用sys.schema来bypass information_schema的，原因是buuoj没有sys.schema_table_statistics_with_buffer这个数据库，但是比赛中是可以利用的，所以还是要作为一个技巧来积累。

1. 开头的注册登录只是幌子,注册账号,进入留言板.
2. 发现注入点:

3. 猜解字段数：-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,因为过滤了‘or‘导致order by无法使用，得用到联合查询一个个试，蛋疼的是有22个字段。 注意最后的引号闭合。
4. 因为环境原因无法bypass得到表名，看了wp知道表名是users。
5. 无列名注入：
1. 猜解users表的字段数，最后得到字段数为3.
2. 使用无列名注入查询字段信息：payload:-1‘union/**/select/**/1,(select/**/group_concat(b)/**/from(select/**/1,2/**/as/**/a,3/**/as/**/b/**/union/**/select/**/*/**/from/**/users)as/**/x),3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,‘22
3.