凌晨惊魂：客户账户被刷走1万块，排查修复全记录

昨晚10点，本来正准备休息，手机突然炸了。客户打电话过来，声音都在抖："系统里被人刷走了1万块钱！"

那一刻，我脑子里"嗡"的一声，脑子里全是数据库、日志、支付网关的碎片。作为一名发际线岌岌可危的程序猿，我深知这不仅是钱的问题，更是信任的崩塌。

紧急响应：先止血，再找病因

挂了电话，我第一反应不是马上查日志，而是先止损。钱已经没了，得防止损失扩大。

深夜排查故障现场

1. 紧急冻结相关账户：通知客户立即冻结涉及支付的所有银行卡和平台账户。
2. 关闭可疑接口：虽然不知道问题在哪，但先把支付相关的写操作接口暂时降级或关闭，避免黑客继续操作。
3. 保留现场证据：第一时间备份了数据库和当天的所有服务器日志。千万别急着重启服务或清空日志，这是破案的关键。

做完这些，大概花了15分钟，心跳终于降到了120以下。

深入排查：黑客是怎么进来的？

接下来就是硬核的排查时间。既然钱是通过系统"刷"走的，那一定在业务流程里留下了痕迹。

网络攻击示意图

1. 分析业务日志

我先去查了交易流水表。果不其然，有一笔异常订单。这笔订单的金额不大，但触发了高频的请求。

查看Nginx访问日志，发现某个IP在短时间内发起了疯狂的请求，而且User-Agent非常可疑，根本不是正常的浏览器标识，大概率是脚本。

2. 接口逻辑漏洞：致命的"越权"

顺着请求ID查到了具体的业务接口。这是一个充值或提现相关的接口。仔细审计代码后，我冷汗下来了——这里存在一个经典的越权漏洞（IDOR）。

简单说，就是接口在处理请求时，只校验了参数的合法性（比如金额必须是数字），却没有校验当前操作用户是否有权限操作这个目标账号。

黑客通过抓包修改了请求中的user_id或account_id，直接用自己低权限的账号，操作了客户的高权限资金账号。系统"傻傻"地执行了，以为就是用户自己的操作。

3. 为什么没被风控拦住？

正常的风控系统应该能识别这种高频异常请求。但我发现，我们的风控规则太松了：

• 没有对单IP的请求频率做严格限制。
• 没有对关键操作（如大额转账）增加二次验证（如短信验证码、Google Authenticator）。
• 异常行为没有触发实时报警机制。

修复方案：亡羊补牢，为时未晚

查到了原因，修复起来就有了方向。为了让客户安心，我也连夜制定了一套整改方案。

1. 代码层面：严格的权限校验

这是最核心的修复。在所有涉及资金变动的接口中，加入了强制性的权限校验逻辑：

// 伪代码示例
if (currentUser.id !== targetAccount.ownerId) {
    throw new Error('无权操作');
}
``

不管前端传什么参数，后端必须从Session或Token中重新解析当前登录用户的真实身份，并以此为基准进行鉴权，永远不要信任客户端传来的ID。

### 2. 增强风控策略

- **限流**：接入了限流中间件，对支付接口实施严格的IP限流和用户限流。比如，同一用户1分钟内只能发起3次提现请求。
- **多因素认证（2FA）**：所有关键操作（修改密码、绑定银行卡、大额提现）必须输入短信验证码或TOTP验证码。
- **异步审计**：将所有资金操作记录写入专门的审计日志表，方便后续追溯。

### 3. 运维层面：监控与报警

- 配置了Prometheus + Grafana监控，关键指标（如每分钟交易量、失败率）一旦超过阈值，立即通过钉钉/企业微信报警。
- 部署了WAF（Web应用防火墙），拦截常见的SQL注入、XSS和恶意扫描。

## 反思：给所有开发者的忠告

这次事故虽然处理完了，但留给我的教训是深刻的。很多时候，我们为了赶进度，会忽略"非功能性"需求，觉得安全是以后的事。

**千万别心存侥幸。**

1. **永远不要信任客户端输入**：所有的参数校验和权限判断，都必须在服务端独立完成。
2. **最小权限原则**：接口只开放必要的权限，不要默认赋予过高的操作能力。
3. **日志就是救命稻草**：完善的日志系统在关键时刻能救你的命，一定要分级记录，并定期归档。
4. **多做安全测试**：上线前，哪怕自己简单做个渗透测试，或者用工具扫一下，都可能发现致命漏洞。

希望这篇复盘能帮大家避坑。如果你也遇到过类似的"惊魂时刻"，欢迎在评论区分享你的经历或避坑指南，毕竟，踩过的坑，才最难忘。