2015年夏天，暴库漏洞我帮一个做电商的暴库漏洞朋友看服务器日志。他的暴库漏洞网站后台突然多了几百个陌生IP，全是暴库漏洞批量请求同一个接口——/api/v1/user/info?uid=后面跟一串数字。他以为是暴库漏洞爬虫，没在意。暴库漏洞三天后，暴库漏洞数据库里多了两万条用户记录，暴库漏洞姓名、暴库漏洞手机、暴库漏洞收货地址全在。暴库漏洞攻击者没黑进系统，暴库漏洞只是暴库漏洞把uid从1遍历到20000，接口没做权限校验，暴库漏洞每请求一次就吐一条完整用户信息。暴库漏洞

这就是暴库。不是SQL注入那种靠拼接语句骗过数据库，也不是拖库——攻击者压根没拿到数据库账号密码。暴库利用的是应用层接口的遍历漏洞，把本不该公开的数据一条条“合法”地取出来。像用一把钥匙挨个试小区所有信箱，钥匙是配的，信箱也没锁。

有人把暴库和撞库搞混。撞库是拿泄露的账号密码去试其他平台，暴库是直接批量拉取数据。前者靠密码复用，后者靠接口设计缺陷。2018年某快递公司被暴库，攻击者通过一个查询订单的接口，把运单号从100000000递增到999999999，每请求一次返回一个完整订单，包括寄件人电话和地址。接口没限频，没鉴权，参数还是自增的。这跟把数据库备份文件放公网下载没区别，只是换了个HTTP接口的形式。

暴库能成功，往往不是技术多高明。开发时图省事，接口直接暴露自增主键。测试时没删调试参数，比如?debug=1&uid=。或者权限校验只在前端做，后端接口裸奔。我见过一个后台管理系统，登录后前端隐藏了“用户管理”菜单，但接口/admin/getUserList没做角色校验。普通用户抓包改个请求，就能拉全量用户。攻击者不需要懂SQL，会写个for循环就行。

防御暴库，核心就一件事：每个请求都要问“你是谁，你凭什么拿这条数据”。接口参数不能用自增ID，换成UUID或哈希。查询必须带当前登录用户的身份，比如/api/user/info只返回token对应的用户，不接受uid参数。限频也管用，单IP每秒超过10次请求直接封。但限频是兜底，不是根治。根治靠权限模型：数据归属谁，谁才能读。

有个做SaaS的朋友，早期接口设计成/api/orders?customer_id=123，任何登录用户都能传任意customer_id。我让他改成/api/my/orders，后端从session取customer_id。改完第二天，日志里还有人在遍历customer_id，但返回全是403。攻击者试了半小时，走了。

暴库漏洞不像SQL注入那样能直接执行命令，但它泄露的数据量往往更大。一个接口一天能被请求几十万次，每次返回一条记录，累积起来就是整个用户表。而且这种攻击在日志里看起来像正常业务请求，流量不大，不会触发WAF。等发现时，数据已经在暗网打包卖了。我见过最离谱的案例，某政务网站查询接口用身份证号做参数，攻击者从生日加顺序码暴力枚举，拉走了全市三分之一的居民信息。接口没验证码，没限频，没权限校验。开发人员说“没想到有人会这么干”。

暴库的本质是信任了不该信任的输入。任何来自客户端的参数——uid、order_id、page、size——都是攻击者可控的。后端必须假设每个请求都是恶意的，然后逐条校验。这不是过度设计，是基本常识。就像你家门锁，不能因为“没想到有人会撬”就不装。