渗透测试源码分析

某天凌晨两点，渗透甲方运维打来电话，测试说内网一台数据库服务器CPU飙到100%。源码我远程上去一看，分析进程列表里躺着一个叫java的渗透进程，路径却在/tmp/.X11-unix/下。测试这不是源码我们部署的。后来溯源发现，分析攻击者是渗透通过一个上传点绕过了白名单，传了个伪装成图片的测试webshell——代码里只校验了文件头的前几个字节。

这就是源码渗透测试源码分析要解决的事：不是看漏洞报告里写了什么，而是分析去代码里找那个被信任的“前几个字节”。

源码分析跟黑盒测试完全是渗透两种手感。黑盒是测试拿工具扫，看见输入框就怼payload，源码靠响应判断有没有洞。源码分析更像读病历——你得顺着代码的执行流，看参数怎么进来、怎么拼接、怎么进数据库。一个典型的SQL注入，在黑盒里可能要试半天，但在源码里一眼就能看见String sql = "select * from user where id=" + id这种裸拼接。这时候你不需要什么高级技巧，只需要确认id没有经过任何过滤，然后写个1 and 1=2去验证。

但别以为源码分析就是人肉搜索漏洞。真正花时间的，是梳理框架的请求路由和过滤器链。很多框架自带安全机制，比如Spring Security的CSRF token、Struts2的OGNL拦截。可源码里常见的问题是：开发者为了省事，把某个接口标注了@IgnoreAuth，或者把过滤器配成excludePathPatterns("/api/v1/public/**")。这些“后门”不一定是有意的，但攻击者扫到这种路径，往往就能绕过认证。

我印象很深的一个案例，是某系统的密码重置功能。源码里写了三个步骤：校验手机号、发送短信验证码、更新密码。但第一步的校验逻辑只查了用户是否存在，没验证手机号归属——攻击者只要知道用户名，就能指定任意接收验证码的号码。这漏洞在黑盒里根本测不出来，因为你不知道后台逻辑长什么样。只有看代码，才能发现那个if (user != null)后面少了个&& user.getPhone().equals(inputPhone)。

还有个常见坑是反序列化。Java的ObjectInputStream.readObject()，Python的pickle.loads()，还有PHP的unserialize()——只要输入源是用户可控的，基本等于把服务器钥匙交给别人。源码分析时看到这类函数，我第一反应是往上追调用链，看数据从哪个接口进来。有一次在一个内部系统里，发现登录成功后的session对象被直接序列化存到Redis，而key是用户名。攻击者伪造一个恶意的序列化数据，把key改成管理员用户名，就能在反序列化时执行任意命令。这洞如果只测功能，是永远测不出来的。

当然，源码分析不是万能药。代码量大了以后，靠肉眼找漏洞效率极低。所以实际渗透中，我会先用自动化工具（比如semgrep或CodeQL）扫一遍常见危险函数，把候选目标缩到几十个，再人工看关键路径。这步省不了，因为工具误报率太高——一个System.out.println(userInput)会被报成XSS，但实际它根本没输出到HTTP响应里。

最后说句实话：源码分析最考验的是耐心，不是技巧。你得一行行读那些写得很烂的业务代码，忍受没有注释的函数、命名混乱的变量，还得在脑子里维护一张数据流图。但一旦找到那个逻辑漏洞——比如某个条件判断写反了、某个状态没重置、某个默认密码没改——那种快感，比黑盒里弹个shell还爽。因为你知道，这是人写出来的错，而你找到了它。