代码审计报告

凌晨两点，代码我把同事写的审计登录模块翻了个底朝天。就在那段看似普通的报告密码重置代码里，藏着一个能让任何账号被接管的代码小漏洞——验证码校验在会话过期后竟然自动通过。这不是审计什么高深的黑客技术，纯粹是报告逻辑顺序写反了。

代码审计这活儿，代码说白了就是审计拿着放大镜找别人藏起来的错误。但多数人以为审计就是报告扫一遍漏洞库，跑几个自动化工具，代码把CVE列表比对一下就完事。审计真这么简单，报告我上周就不会在自家系统里翻出三个高危问题了。代码

上周那个案例挺典型。审计支付回调接口用MD5做签名校验，报告这本身没错，错在把签名参数也拼进了待验签的字符串里。攻击者只要改掉金额字段，顺手把签名也改一下，服务端拿到的就是“合法”请求。这种低级失误，工具根本扫不出来，得靠人盯着业务逻辑一步步推演。

另一个让我印象深刻的坑发生在文件上传功能。开发团队明明做了类型白名单，却在存储路径上用了用户可控的文件名。结果攻击者构造一个../../shell.php的路径，白名单形同虚设。审计时我盯着那行代码看了十分钟，差点笑出声——安全措施做得越复杂，越容易在细节上翻车。

真正的审计核心其实不在代码本身。我习惯先看开发者的编程习惯，再顺着他的思维走一遍。有人喜欢用全局变量传参，有人爱把校验逻辑堆在控制器里，这些风格差异往往决定了漏洞藏身的位置。有个老前辈教过我：先找最“自信”的代码，因为写的人越确信没问题，越容易忽略边界情况。

最近一次审计碰到个有趣现象：团队里资历最浅的实习生写的代码反而最干净。问起来才知道，他每写一个函数都会自己先模拟攻击一遍。这种习惯比任何安全培训都管用。反过来看，那些写了十年业务代码的老手，反而容易陷入惯性思维——比如默认数据库里的数据都是可信的。

审计报告写得再漂亮，不落地执行就是废纸。上周给某团队提了十七条整改建议，真正被采纳的只有三条。问原因，答曰“排期太满”。这也没办法，安全永远在跟业务抢时间。但我始终认为，代码审计的价值不在于找茬，而在于帮团队建立一种“被攻击者视角”。

最后说个细节：审计时我总爱留意注释。如果一段复杂逻辑旁边没有任何注释，这本身就是个危险信号。写注释的人未必懂安全，但完全不留注释的代码，多半是赶工赶出来的——赶工意味着什么，做过开发的都懂。