第二章、遇到阻难，绕过waf
0x01. 寻找注入点
进入靶场
寻找注入点
http://59.63.200.79:8004
一般新闻都会和数据库有交互，可以尝试在这个地方寻找注入点
看到id你还不欣喜若狂，接下来就开始测试吧，而且还是一个asp的网站，怀疑后台用的是access数据库
?id=172
?id=173
通过改变id参数的值，发现页面呈现不同的内容，可以判断应该是和数据库有交互，有回显，可以尝试联合注入
0x02. 绕过waf
?id=173'
遇到这个情况就很尴尬，通过get方式注入是不行了，哪还有什么方法呢，常见的有get，post，cookie，一般
cookie提交的数据是不进行过滤的，心动不如行动，开始BP抓包测试
开启代理，将抓到的数据包，发给重发器进行测试调节
发现果然通过cookie可以传递id参数
单引号测试
id=171'
数据库报错，但是并没有将报错信息显示出来，显然报错注入这种方法你不要想了
0x03. 注入手法
测试闭合方式
id=171'
id=171 and 1=1
id=171' and 1=1--+
发现全部返回数据库出错,我醉了,我直接默认是数字型注入,开始order by
id=171+order+by+1,2,3,4,5,6,7,8,9
没有报错，我激动不已，可以说明两点，一是数字型注入，二是查询的字段个数大于9
id=171+order+by+1,2,3,4,5,6,7,8,9
id=171+order+by+1,2,3,4,5,6,7,8,9,10,11
到11的时候，没有结果返回，说明字段个数只有10，嘿嘿他还凑个整，真的是够了
判断数据在当前页面显示的位置
id=1711+union+select+1,2,3,4,5,6,7,8,9,10+ 代表空格
tmd竟然报错了，不讲道理啊，这语句没毛病啊，经过我深沉的思考后，难道后台真的是access数据库，不管了
先试一试，在access数据库中使用union select后面必须要接表名，这点特别恶心，既然是找后台，那么估计
八九不离十的有一个admin表，来一发试一试
id=1711+union+select+1,2,3,4,5,6,7,8,9,10+from+admin
乖乖老实了吧，不数据库报错了吧
既然是access数据库，那就没办法像mysql数据库那样靠information_schema这个库去查表名，字段名了
这种数据库的注入全靠猜，既然前面已经猜出来有admin表了，估计表下面会有id，username，password
这三个字段，别问我为什么知道这些，你写个项目就知道了
id=1711+union+select+1,username,password,4,5,6,7,8,id,10+from+admin+limit+0,1
果然出来了，但是密码应该md5摘要后的，注意md5不是加密算法，野生程序员注意啦，我多年口算md5的经验
告诉我，这是welcome，但是秉承着一向严谨的态度，证实一下我的口算
我这口算依然是屡试不爽啊
0x04. 登录后台
既然要登录后台，但是我没有后台的地址啊
你是不是想到了7kb,破壳这种扫描网站目录的工具，但是你忽略了题目的提示，默认后台，老司机的你还没想到
admin吗？
http://59.63.200.79:8004/admin/ 会自定跳到后台登录页面账号：admin密码：welcome
0x05. 总结
遇到access数据库，就看你会不会猜表名，字段名了，还要注意的是access数据库中使用union select 联合查询
的时候后面一定要接from 表名