代码审计的三种方式

去年帮一个朋友看他的代码的种小项目，一个基于Spring Boot的审计商城后台。他跟我说"应该没啥问题"，代码的种结果我打开IDEA，审计翻了不到二十分钟，代码的种就在一个导出订单的审计接口里发现了SQL拼接。参数直接从`HttpServletRequest`里取，代码的种连个`PreparedStatement`都没用。审计这就是代码的种代码审计最原始的形态——靠眼睛看，靠经验猜。审计

人工审计这事，代码的种说白了就是审计"人肉模式匹配"。你脑子里得存着一堆危险函数的代码的种黑名单：Java里的`Runtime.exec`、PHP里的审计`eval`、Python里的代码的种`pickle.loads`。看到用户输入流进这些地方，警报就得响。但人有个毛病，看代码超过两小时就开始走神。我自己的经验是，一次深度审计别超过90分钟，否则第十次看到`getParameter`的时候，你会觉得它人畜无害。

工具审计是另一条路。SonarQube、Fortify、Semgrep，这些我都用过。SonarQube配好规则跑一遍，报告能出几百页。问题是误报太多。有一次它标了一个"资源未关闭"的严重问题，我点进去一看，是个`StringBuilder`。工具不懂业务上下文，它只知道语法树上的模式。但工具的好处是快，而且不会累。半夜三点让它跑，第二天早上看结果，适合做第一轮粗筛。

真正有意思的是第三种——动态审计。你得把应用跑起来，用Burp Suite或者自己写脚本去戳。静态看代码看不出问题的场景太多了。比如一个反序列化漏洞，静态分析可能只看到`readObject`，但到底能不能被利用，得实际发个payload试试。我之前遇到一个XXE，代码里明明禁用了外部实体，但用的是老版本DOM4J，实际请求发出去，OOB带外数据还是出来了。静态看一百遍不如动态跑一遍。

三种方式不是互斥的。我自己的流程通常是：Semgrep跑一遍拿个底稿，然后人工过一遍关键路径，最后动态验证可疑点。工具负责广度，人负责深度，动态负责确认。但很多人只做第一步，拿着工具报告就去交差，漏掉的东西比找到的多。

说个具体的。上个月审一个Go写的API网关。静态看，所有数据库操作都用了ORM，没毛病。但我注意到一个中间件里，`X-Forwarded-For`头被直接拼进了日志。日志本身不执行，但日志会被Filebeat采集，发到Elasticsearch。如果攻击者构造一个包含换行符的IP，就能往ES里注入伪造的日志条目。这个点，静态工具不会报，因为它不是传统意义上的"漏洞"。动态测试也难发现，因为得知道整个日志管道。只有人工审计，结合对架构的理解，才能看出来。

代码审计到最后，拼的不是工具多牛，是你对"数据从哪来、到哪去、中间经过了什么"的理解。工具能帮你画地图，但走路的还是你自己。别指望一键出报告，那东西只能用来应付合规检查。真要有用，还得自己一行一行看，一个请求一个请求发。