1. 从一次应急响应说起：为什么要同时掌握Java和PHP两条审计线
很多做安全的人都有一个习惯，就是给自己贴标签——"我是搞Java安全的"或者"我是搞PHP的"。这个标签在平时接项目的时候确实能帮你聚焦，但真到了应急响应或者红队复盘的时候，你会发现攻击者从来不管你擅长什么。我印象很深的一次，某业务系统对外暴露的是一个PHP写的管理后台，但后台调用的核心业务接口是Spring Boot写的。攻击者先是通过PHP后台的一个文件上传点拿到了WebShell，然后顺着配置文件里的数据库连接串横向到了Java服务，最后用Java端的反序列化漏洞把整个内网打穿了。整个链路横跨两种语言，如果你只懂一边，排查到一半就断了。
这就是我想写这篇东西的原因。Java-PHP源码审计不是一个"两选一"的命题，而是一套需要打通的方法论。Java的生态庞大、框架层次深、编译产物多，审计时更像是在做"逆向+配置梳理"；PHP的生态碎片化、动态特性强、框架版本差异大，审计时更像是在做"模式匹配+数据流追踪"。两者的思路有交集，但侧重点完全不同。把这两条线都摸清楚，你在面对混合技术栈的目标时才能做到心里有底。
这篇文章适合谁看？如果你已经能看懂基本的Java和PHP代码，知道什么是SQL注入、什么是反序列化，但拿到一整套源码时不知道从哪里下手，那这篇内容就是给你准备的。我会从审计流程的搭建讲起，然后分别拆Java和PHP的审计要点，再讲漏洞溯源的技巧，最后聊一些实战中踩过的坑。全程不堆概念，只讲能直接上手用的东西。
提示：本文讨论的所有技术内容仅用于授权的安全测试和代码审计工作，请务必在合法合规的前提下使用。
2. 审计前的准备工作：环境、工具与心态
2.1 拿到源码后的第一件事不是打开IDE
很多人拿到源码压缩包，第一反应是解压然后用IDE打开，开始一个文件一个文件地看。这个习惯非常低效。我自己的流程是：先不打开任何代码文件，而是先做"结构侦察"。
具体怎么做？先在命令行里把目录树打出来，看整体结构。对于Java项目，你要关注的是：有没有pom.xml或者build.gradle，有几个模块，WEB-INF下面有没有web.xml，有没有application.properties或application.yml。对于PHP项目，你要关注的是：入口文件在哪（index.php、admin.php），有没有composer.json，有没有框架特征目录（比如application/、thinkphp/、vendor/laravel/）。
这一步的目的是建立"地图感"。你得先知道这个项目有多大、用了什么框架、大概有哪些功能模块，然后再决定从哪里切入。上来就啃代码，很容易迷失在细节里。
2.2 工具链的搭配逻辑
工具不在多，在于搭配合理。我常用的组合是这样的：
| 用途 | Java方向 | PHP方向 |
|---|---|---|
| 依赖梳理 | Maven/Gradle依赖树、mvn dependency:tree | composer.lock解析、composer show |
| 静态扫描 | CodeQL、Semgrep、Fortify | RIPS、Semgrep、Psalm |
| 反编译 | JD-GUI、CFR、Procyon | 无（PHP是解释型） |
| 动态调试 | IDEA远程Debug、Arthas | Xdebug + VSCode/PHPStorm |
| 辅助搜索 | grep、ripgrep、Everything | grep、ripgrep、ack |
这里重点说两个容易被忽略的工具。一个是ripgrep，它比grep快得多，而且默认支持递归搜索和.gitignore过滤，在大型项目里搜关键字效率极高。另一个是Semgrep，它支持自定义规则，你可以把常见的危险模式写成规则，批量扫描整个项目。比如你可以写一条规则匹配所有Runtime.getRuntime().exec(的调用，然后快速定位命令执行点。
注意：静态扫描工具的结果只能作为线索，不能作为结论。工具报出来的问题需要人工确认，工具没报出来的问题不代表不存在。我见过太多人过度依赖工具，结果漏掉了最关键的逻辑漏洞。
2.3 心态准备：审计是体力活，也是脑力活
说句实话，代码审计的很大一部分工作是重复性的——搜索关键字、追踪变量、确认过滤逻辑。这个过程很枯燥，但你不能跳过。我的经验是，把审计分成"粗筛"和"精读"两个阶段。粗筛阶段用工具和关键字快速过一遍，标记出可疑点；精读阶段针对可疑点逐个深入分析。这样既能保证覆盖面，又不会在无关代码上浪费太多时间。
另外，一定要养成做笔记的习惯。审计过程中你会遇到大量的类名、方法名、参数名，光靠脑子记不住。我一般用Markdown记一个审计日志，记录每个可疑点的位置、分析结论、待确认事项。这个日志在后续写报告的时候会省你很多事。
3. Java源码审计的核心切入点
3.1 先看配置文件，再看代码
Java项目的配置文件里藏着大量信息。application.yml或者application.properties里可能有数据库密码、Redis密码、第三方API密钥。web.xml里能看到所有的Servlet映射和Filter配置。pom.xml里能看到所有依赖的版本号，直接对应已知漏洞。
我审计Java项目的时候，第一步永远是看依赖版本。比如看到fastjson 1.2.24，不用看代码就知道大概率有反序列化问题；看到shiro 1.2.4，就知道默认密钥的问题可能存在；看到log4j-core 2.14.1，就知道Log4Shell的影响范围。这一步能帮你快速锁定高价值目标。
<!-- 典型的pom.xml依赖片段，版本号是审计的第一线索 --> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.24</version> </dependency>3.2 入口点梳理：从Controller到Servlet
Java Web应用的入口点主要有几类：Spring MVC的@Controller/@RestController、Servlet的doGet/doPost、Filter和Interceptor、WebSocket端点、定时任务等。你需要把这些入口全部找出来，然后逐个分析每个入口的参数处理逻辑。
对于Spring项目，搜索@RequestMapping、@GetMapping、@PostMapping这些注解就能快速定位所有HTTP入口。对于传统Servlet项目，搜索extends HttpServlet或者web.xml里的<servlet-mapping>。找到入口之后，重点看参数是怎么接收的——是@RequestParam、@PathVariable还是@RequestBody，不同类型的参数处理方式不同，安全风险也不同。
3.3 数据流追踪：从Source到Sink
这是Java审计的核心方法论。Source就是用户可控的输入点，Sink就是危险操作点。你要做的是追踪数据从Source到Sink的完整路径，看中间有没有有效的过滤。
常见的Source包括：HTTP请求参数、HTTP头、Cookie、文件上传内容、数据库读取的数据（二次注入场景）。常见的Sink包括：Runtime.exec()、ProcessBuilder、Statement.execute()、ObjectInputStream.readObject()、FileOutputStream、Response.getWriter().write()等。
追踪的过程中，要特别注意"净化函数"——也就是那些做了安全处理的函数。比如Integer.parseInt()会把字符串转成整数，天然免疫SQL注入；StringEscapeUtils.escapeHtml4()会做HTML转义，能防XSS。但要注意，净化函数用错了地方或者用错了顺序，等于没净化。
// 看似安全的写法，实际上如果id来自用户输入且未做类型校验，仍可能出问题 String id = request.getParameter("id"); int userId = Integer.parseInt(id); // 这里如果id不是数字会抛异常，但至少防了注入 String sql = "SELECT * FROM users WHERE id = " + userId;3.4 反序列化：Java审计绕不开的坎
Java反序列化漏洞是Java安全里最经典也最复杂的一类。审计的时候，你要找的是readObject()的调用点，然后看能不能控制传入的字节流。常见的触发点包括：HTTP请求体直接反序列化、RMI通信、JMS消息、缓存读取等。
但找到readObject()只是第一步，你还需要确认classpath里有没有可以利用的gadget chain。这就回到了依赖梳理——commons-collections、fastjson、jackson、xstream这些库的特定版本都可能提供gadget。实际审计中，我一般会先确认目标环境里有哪些库，然后再去构造利用链。
3.5 框架特性带来的"隐形"漏洞
Java框架的很多特性在方便开发的同时也引入了安全风险。举几个例子：
- Spring Boot Actuator：如果
management.endpoints.web.exposure.include配置为*，那么/actuator/env、/actuator/heapdump等端点会直接暴露敏感信息。 - Spring Cloud Gateway：SpEL表达式注入问题在特定版本中存在。
- Shiro：默认密钥问题、权限绕过问题。
- Struts2：OGNL表达式注入，历史漏洞极多。
审计的时候，看到这些框架就要条件反射地去查对应版本的已知漏洞。这不是偷懒，而是效率最高的做法。
4. PHP源码审计的独特打法
4.1 PHP项目的"入口"比Java更分散
PHP没有Java那种统一的Servlet容器概念，入口文件可能有很多个。一个典型的PHP项目可能有index.php、admin.php、api.php、upload.php等多个入口，每个入口都可能直接接收用户输入。所以审计PHP项目的第一步是找全所有入口文件。
怎么找？搜索$_GET、$_POST、$_REQUEST、$_COOKIE、$_FILES、$_SERVER这些超全局变量的使用位置。每一个使用点都是一个潜在的Source。然后顺着这些变量往下追，看数据流向了哪里。
4.2 危险函数清单：PHP审计的基本功
PHP的危险函数比Java更直观，因为很多函数本身就是"危险"的代名词。下面这张表是我审计时必查的：
| 漏洞类型 | 危险函数 | 审计要点 |
|---|---|---|
| 命令执行 | system、exec、shell_exec、passthru、popen、proc_open、反引号 | 参数是否可控，是否有拼接 |
| 代码执行 | eval、assert、preg_replace（/e修饰符）、create_function、call_user_func | 参数来源，是否可绕过 |
| 文件包含 | include、require、include_once、require_once | 路径是否可控，是否允许远程 |
| 文件操作 | file_get_contents、file_put_contents、fopen、unlink、rename | 路径是否可控，是否有目录穿越 |
| SQL注入 | mysql_query、mysqli_query、PDO::query | 是否拼接，是否用了预处理 |
| 反序列化 | unserialize | 参数是否可控，是否有__wakeup/__destruct魔术方法 |
这张表不是让你死记硬背，而是让你在审计时有一个检查清单。看到这些函数，就要停下来仔细看参数是怎么传进来的。
4.3 框架路由与MVC结构的影响
现代PHP项目大多用框架，比如Laravel、ThinkPHP、Symfony、Yii。框架会改变审计的方式。以ThinkPHP为例，它的路由规则、控制器命名、参数绑定方式都有特定的模式。你需要先理解框架的路由解析逻辑，才能知道一个URL对应的是哪个控制器、哪个方法。
ThinkPHP历史上出过很多RCE漏洞，比如5.0.x的captcha路由问题、5.1.x的request方法调用问题。这些漏洞的根源都是框架在处理用户输入时没有做好过滤。审计ThinkPHP项目时，要特别关注app目录下的控制器代码，以及route目录下的路由定义。
Laravel相对安全一些，但也不是没有问题。比如unserialize的使用、env文件的暴露、debug模式下的信息泄露等。审计Laravel项目时，要关注config目录、.env文件、routes目录。
4.4 文件上传与文件包含：PHP的重灾区
PHP的文件上传漏洞之所以多，很大程度上是因为早期教程里充斥着不安全的写法。很多老项目的上传逻辑是这样的：检查文件扩展名，如果不在黑名单里就允许上传。这种黑名单机制很容易被绕过——php3、php5、phtml、pht等扩展名可能不在黑名单里，但服务器可能仍然会解析。
审计文件上传功能时，要重点看几个点：扩展名检查逻辑、MIME类型检查逻辑、文件内容检查逻辑、上传后的文件存储路径、文件是否可被直接访问。任何一个环节有问题，都可能导致GetShell。
文件包含漏洞的审计要点是：包含的路径是否可控、是否允许远程包含（allow_url_include）、是否有php://input等伪协议可以利用。本地文件包含（LFI）配合文件上传，往往能形成完整的攻击链。
4.5 变量覆盖与魔术方法：PHP的"暗坑"
PHP的extract()函数、parse_str()函数、$$可变变量等特性，可能导致变量覆盖漏洞。比如一个函数用extract($_GET)把请求参数导入到当前作用域，攻击者就可以覆盖函数内部的变量，改变程序逻辑。
魔术方法是PHP面向对象编程里的特殊方法，以__开头，比如__construct、__destruct、__wakeup、__toString、__call、__get、__set。这些方法在特定条件下会被自动调用，如果里面有不安全的操作，就可能被利用。审计PHP反序列化漏洞时，核心工作就是找一条从unserialize入口到危险魔术方法的利用链。
// 一个典型的魔术方法利用场景 class FileHandler { public $filename; public function __destruct() { // 如果filename可控，这里就可能删除任意文件 unlink($this->filename); } } // 攻击者构造序列化数据，控制filename属性5. 漏洞溯源：从现象反推根因
5.1 溯源的本质是"逆向数据流"
漏洞溯源和代码审计的方向是相反的。代码审计是从Source找Sink，溯源是从Sink反推Source。当你发现一个漏洞点（比如一个命令执行），你需要回答几个问题：这个危险函数的参数是从哪里来的？经过了哪些处理？有没有可能被用户控制？
这个过程需要你对代码的调用关系有清晰的理解。我的做法是，从危险函数开始，一层一层往上追。比如看到Runtime.exec(cmd)，先看cmd变量在当前方法里是怎么赋值的，如果是方法参数，就找谁调用了这个方法，一直追到HTTP入口。
5.2 利用调用链分析工具提效
手工追调用链很累，尤其是大型项目。这时候可以用一些工具辅助。IDEA的"Find Usages"功能可以快速找到方法的所有调用点。CodeQL可以写查询语句，自动追踪数据流。Arthas可以在运行时观察方法的调用栈。
但工具不是万能的。Java的动态代理、反射调用、Spring的依赖注入等机制，会让静态分析工具"看走眼"。所以工具给出的结果需要人工验证，不能全信。
5.3 日志与流量：溯源的另一条路
有时候你拿不到源码，或者源码不完整，这时候日志和流量就是重要的线索。Web访问日志能告诉你攻击者访问了哪些URL、传了什么参数。如果开启了POST日志，还能看到请求体。结合WAF日志、数据库日志、系统日志，可以还原出攻击的完整过程。
我处理过一次应急，目标是一个PHP站点，源码被加密了（用了类似dezend的工具）。我们拿不到明文源码，但通过分析Nginx的access log，发现攻击者访问了一个异常的URL，参数里带有明显的命令执行特征。顺着这个URL，我们在加密源码里定位到了对应的文件，虽然代码是加密的，但通过行为分析还是确认了漏洞点。
5.4 常见漏洞的溯源模式
不同类型的漏洞，溯源时有不同的关注点：
- SQL注入：追参数到SQL语句的拼接过程，看有没有预处理、有没有转义。
- 命令执行：追参数到命令拼接的过程，看有没有白名单校验。
- 反序列化：追字节流到
readObject/unserialize的路径，看有没有过滤。 - 文件上传：追文件名和文件内容到存储路径的过程，看校验逻辑。
- SSRF：追URL参数到HTTP请求发起的过程，看有没有协议限制和IP限制。
掌握这些模式之后，溯源就变成了"按图索骥"，效率会高很多。
6. 实战中踩过的坑与经验总结
6.1 不要忽略"业务逻辑漏洞"
代码审计工具擅长发现技术型漏洞（注入、XSS、反序列化），但对业务逻辑漏洞几乎无能为力。比如越权访问、支付逻辑绕过、验证码复用、密码重置逻辑缺陷等。这些漏洞需要你理解业务，站在攻击者的角度思考"这个功能有没有可能被滥用"。
我审计过一个电商系统，技术层面做得很扎实，参数化查询、输出编码、CSRF Token都有。但它的优惠券领取接口没有做频率限制，也没有校验用户是否已经领取过。结果就是可以无限领取优惠券，造成资损。这种漏洞，工具是扫不出来的。
6.2 版本信息比代码本身更重要
很多时候，你不需要逐行读代码，只需要确认组件版本，就能判断是否存在已知漏洞。所以审计时一定要花时间梳理依赖版本。Java看pom.xml和lib目录，PHP看composer.lock和vendor目录。把版本号和CVE数据库比对，能快速找到高价值目标。
6.3 过滤逻辑要看"上下文"
看到一个过滤函数，不要急着下结论说"这里安全了"。要看这个过滤函数是在什么上下文里使用的。比如htmlspecialchars()在HTML上下文里能防XSS，但如果输出点在JavaScript代码块里，htmlspecialchars()就不够了，需要json_encode()。再比如addslashes()能防SQL注入，但如果数据库连接使用了GBK编码，宽字节注入就可能绕过它。
6.4 审计报告要能"复现"
写审计报告的时候，不要只写"这里存在SQL注入"，要写清楚：漏洞文件路径、漏洞代码行号、触发URL、请求方法、请求参数、Payload示例、预期结果。这样开发人员才能快速定位和修复，复测人员也能快速验证。我见过太多报告只写一个漏洞名称，开发看了半天不知道说的是哪里。
6.5 持续学习：漏洞库和社区
代码审计是一个需要持续学习的方向。新的框架、新的组件、新的漏洞类型层出不穷。我的习惯是定期看几个地方：GitHub上的安全公告、CVE数据库、Seebug漏洞平台、先知社区、安全客。不需要每篇都精读，但要知道最近有什么新漏洞、影响哪些版本。这样在审计时，看到相关组件就能立刻联想到。
6.6 关于自动化的一些思考
现在有很多自动化代码审计工具，比如CodeQL、Fortify、Checkmarx。这些工具确实能提高效率，但它们不能替代人工审计。工具擅长发现模式化的漏洞，但面对复杂的业务逻辑、框架特性、绕过技巧时，还是需要人来判断。我的建议是：把工具当作"助手"，用它来做初筛和辅助追踪，但最终的判断和深入分析还是要靠人。
另外，自己写一些小的脚本也很有用。比如写一个Python脚本，批量提取Java项目里所有的@RequestMapping路径；或者写一个脚本，批量检查PHP项目里所有的unserialize调用点。这些脚本不复杂，但能省很多时间。
7. 两条线打通之后的能力边界
把Java和PHP两条审计线都摸清楚之后，你会发现自己的能力边界扩展了很多。面对一个混合技术栈的目标，你能快速判断从哪里切入、用什么方法、重点关注什么。面对一个未知的源码包，你能在短时间内建立起"地图感"，找到高价值的审计点。面对一个应急事件，你能从日志和流量出发，逆向还原攻击链路。
但也要清楚自己的边界。代码审计只是安全测试的一个环节，它不能替代渗透测试、不能替代配置核查、不能替代安全开发生命周期管理。审计发现的漏洞需要修复和验证，审计没发现的漏洞不代表不存在。保持敬畏，保持学习，才是这个方向能走远的关键。
最后分享一个我自己的小习惯：每次审计完一个项目，我会把遇到的典型漏洞模式、绕过技巧、工具用法整理成一个笔记。时间长了，这个笔记就成了我自己的"审计知识库"。下次遇到类似的项目，翻一翻笔记，往往能快速找到思路。这个习惯看起来笨，但确实管用。
