《网站盲注》

一个登录框，网站盲注输入单引号，网站盲注页面返回“SQL语法错误”。网站盲注就这一行报错，网站盲注整台服务器的网站盲注数据库可能已经向攻击者敞开了大门。盲注，网站盲注说白了就是网站盲注在看不见回显的情况下，靠一个又一个“是网站盲注”或“否”的答案，把数据库里的网站盲注数据一点一点猜出来。听起来笨，网站盲注但极其有效。网站盲注

我最早接触盲注是网站盲注在一个朋友的接单项目里。目标站是网站盲注个老旧的CMS，输入id=1正常，网站盲注id=1'报错，网站盲注id=1 and 1=1正常，id=1 and 1=2返回空页面。典型的布尔盲注。没有回显位，没有联合查询的空间，只能靠页面正常与否来判断条件真假。当时我写了个Python脚本，用二分法逐字符猜数据库名。第一个字符猜了七次请求才确定是i，整张表名跑完花了将近四十分钟。慢，但确实进去了。

盲注分三类。布尔盲注靠页面状态差异判断真假，时间盲注靠sleep()函数的响应延迟判断，报错盲注则依赖数据库报错信息里的细微差别。布尔盲注最直观，也最容易被WAF拦截，因为请求里全是and、or、substr这类敏感词。时间盲注更隐蔽，id=1 and if(ascii(substr(database(),1,1))>100,sleep(3),0)，页面内容完全正常，只是慢了3秒。很多运维根本不会注意到这几秒的延迟。

有个细节值得说。MySQL里substr()和mid()等价，ascii()和ord()等价，攻击者会轮换着用绕过黑名单。更老练的做法是用benchmark()替代sleep()，或者用case when替代if。WAF规则更新永远慢半拍，这不是技术问题，是成本问题——你不可能为每个站点的每个参数都写一条精准规则。

手工盲注不现实。猜一个32位的MD5哈希，按二分法算，每个字符平均7次请求，总共224次。手工敲URL敲到手指发酸。所以盲注必然依赖工具，sqlmap是标配，但sqlmap的盲注模式噪音太大，默认的--threads=10会在日志里留下密集的请求记录。我习惯把--delay=2加上，再把--random-agent打开，请求间隔拉长到2秒以上，看着像正常用户翻页。速度是慢，但不容易触发告警。

防御盲注的思路和防御普通注入没有本质区别。参数化查询是唯一彻底的办法。但现实里大量老系统用的是字符串拼接，改造成本高到没人愿意动。退而求其次，统一错误页面、限制数据库账户权限、对sleep和benchmark做函数级拦截，能挡住大部分自动化扫描。真正麻烦的是业务逻辑盲注——比如通过订单状态变化推断其他用户的数据，这种不走SQL语法，WAF基本无能为力。

我见过最离谱的案例是一个站把id参数直接拼进order by后面。没有回显，没有报错，但页面排序结果会变。攻击者用order by if(1=1,id,username)，通过观察排序顺序就能逐字提取数据。这种注入点sqlmap默认检测不到，得手动指定--technique=B并且调高--level。发现它纯粹是因为我那天无聊，把每个参数后面都加了个逗号看反应。

盲注的本质是把数据库变成一个只能回答“是”或“否”的黑盒。攻击者要做的，就是设计足够多的问题，把黑盒里的信息熵一点一点榨出来。这个过程枯燥、缓慢，但一旦跑通，整个数据库就是透明的。对防守方来说，与其纠结怎么过滤关键字，不如先把错误回显关掉，再把数据库权限砍到最低。剩下的，交给参数化查询。