当前位置：首页 > news >正文

Java代码审计入门：从Hello-Java-Sec靶场到SQL注入实战

news 2026/6/28 21:01:49

1. 项目概述：为什么从“Hello-Java-Sec”开始？

如果你对网络安全感兴趣，尤其是想往应用安全方向发展，那么“代码审计”这个词你一定不陌生。它听起来很高大上，仿佛需要你立刻精通Java虚拟机、熟悉所有框架源码、一眼就能看出百万行代码里的安全漏洞。很多新手就是被这种想象吓退了，觉得门槛太高，无从下手。其实，任何复杂技能的起点，都可以是一个简单的“Hello World”。今天我们要聊的这个“Hello-Java-Sec”，就是代码审计领域的“Hello World”。它不是某个复杂的、存在无数漏洞的CMS系统，而是一个专门为学习代码审计而设计的、靶场性质的开源项目。它的核心价值在于，将那些在真实审计中需要花费大量时间才能遇到的、分散在各处的安全漏洞，精心设计并集中展示在一个结构清晰、代码量适中的项目里。这就像学游泳，与其直接跳进波涛汹涌的大海，不如先在一个标准泳池里，在教练的指导下，从换气、漂浮这些基本动作练起。“Hello-Java-Sec”就是这个泳池。

那么，这个项目具体能解决什么问题呢？它主要面向三类人：一是安全专业的在校学生，课本上的理论需要实践来印证；二是刚入行的安全工程师，需要快速建立对Java Web漏洞的直观感受和审计手感；三是甚至是一些开发人员，想了解自己的代码可能从哪些角度被攻击，从而写出更安全的程序。通过这个项目，你可以系统地、无压力地接触到SQL注入、命令执行、文件上传、反序列化、SSRF（服务器端请求伪造）等最常见的Web安全漏洞。更重要的是，它教你如何从一个黑盒测试者（只知道输入和输出）转变为一个白盒审计者（能看到代码逻辑），去理解漏洞为什么会产生，以及如何在代码层面修复它。这第一步，就从读懂这个“Hello-Java-Sec”开始。

2. 核心漏洞类型与审计入口点解析

一个Java Web应用，无论框架如何演变，其处理用户请求的基本模式是相对固定的：接收输入、处理逻辑、访问数据（数据库、文件、外部服务）、返回结果。漏洞就潜伏在这个流程的每一个环节。审计时，我们通常沿着两条主线进行：一是“数据流”，跟踪用户可控的输入从哪里进入，流经了哪些函数和方法，最终在哪里被使用；二是“控制流”，关注程序的关键执行路径和条件判断。对于“Hello-Java-Sec”这类学习项目，我们可以按漏洞类型来划分审计入口点，这样更有条理。

2.1 SQL注入：寻找拼接的字符串

SQL注入的根源在于将用户输入的数据与SQL语句进行字符串拼接，而非使用预编译的参数化查询。在Java中，审计的典型入口点是寻找Statement接口（特别是java.sql.Statement和java.sql.PreparedStatement的误用）的使用，以及各种字符串拼接操作（如+、StringBuilder.append、String.format）。

注意：并非所有使用Statement就一定存在注入，如果其执行的SQL语句完全由硬编码的常量构成，与用户输入无关，则是安全的。但这是一个需要高度警惕的信号。

在审计时，我会重点查看Controller（或Servlet）中获取参数的方法（如HttpServletRequest.getParameter），然后跟踪这个参数变量后续的传递路径。如果它最终被传递到了类似下面的代码模式中，风险就极高：

String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"; Statement stmt = connection.createStatement(); ResultSet rs = stmt.executeQuery(sql);

审计技巧在于，不要只看一层。有时参数会经过service层、dao层多次传递，或者被封装进一个对象。你需要像侦探一样，沿着调用链追查下去。在“Hello-Java-Sec”中，这类漏洞通常会放在非常明显的位置，帮助你建立最初的敏感度。

2.2 命令执行与文件操作：警惕Runtime.exec和文件路径穿越

命令执行漏洞通常源于调用了Runtime.getRuntime().exec()或ProcessBuilder，并且其参数的一部分或全部来自用户输入。审计时，搜索这些关键字是第一步。但更关键的是分析参数是否被安全地处理。即使命令本身是固定的，如果参数可控，攻击者依然可以通过注入空格、分号、反引号、管道符等来执行任意命令。

文件操作漏洞则包括任意文件读取、删除、写入（配合文件上传可能形成Webshell）以及目录穿越（Path Traversal）。审计入口点是java.io.File相关的操作、Files类的方法，以及像Servlet的getResourceAsStream、getRealPath等。核心风险点在于，文件路径是否由用户输入直接或间接控制，且没有进行正确的规范化（normalize）和校验。例如：

String fileName = request.getParameter("file"); File file = new File("/base/dir/" + fileName);

如果用户传入../../../etc/passwd，就可能读取到系统敏感文件。在审计时，要检查是否有对../或空字节（%00，虽然在高版本JDK中影响有限）的过滤，以及是否将用户输入限制在预期的目录内（使用Paths.get(basePath, userInput).normalize()并检查是否仍以basePath开头是更安全的做法）。

2.3 反序列化：不可信的ObjectInputStream

Java反序列化漏洞是近年来非常高危的一类漏洞，可能直接导致远程代码执行。其审计入口点相对集中：寻找那些直接或间接接收外部数据并调用ObjectInputStream.readObject()方法的地方。常见的场景包括：

HTTP请求参数、Cookie、Header中包含经过Base64或其他编码的序列化数据，服务端直接对其进行反序列化。
使用RMI、JMX、JMS等协议进行通信，而这些协议底层使用了Java序列化。
框架或组件特定的入口，如Apache Commons Collections、Fastjson、Jackson、XStream等库在特定配置下触发的问题。

在“Hello-Java-Sec”中，为了教学目的，可能会提供一个非常直观的、从HTTP请求中读取字节流并进行反序列化的Servlet示例。审计时，看到readObject()就要立刻绷紧神经，思考这个流的来源是否完全可信。一个基本原则是：永远不要反序列化来自不受信源的任何数据。如果业务必须使用，则应考虑使用白名单机制限制反序列化的类，或者使用更安全的替代方案如JSON、Protocol Buffers。

2.4 SSRF与XXE：外部资源与XML解析

SSRF（服务器端请求伪造）漏洞的成因是应用提供了从服务器发起网络请求的功能（如下载图片、获取远程内容、调用内部API），但请求的URL地址用户可控且未做有效限制。审计入口点是寻找使用HttpURLConnection、URLConnection、OkHttpClient、Apache HttpClient等HTTP客户端库的代码，并检查其URL参数来源。

XXE（XML外部实体注入）漏洞发生在解析XML输入时，如果解析器配置不当，允许解析外部实体，则可能导致文件读取、内网探测甚至远程代码执行。审计入口点是寻找DocumentBuilderFactory、SAXParserFactory、XMLInputFactory等XML解析器的初始化代码。关键检查点在于是否设置了FEATURE_SECURE_PROCESSING，以及是否显式地禁用DTDs（Document Type Definitions）和外部实体。例如，安全的配置应该类似：

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); dbf.setFeature("http://xml.org/sax/features/external-general-entities", false); dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false); dbf.setXIncludeAware(false); dbf.setExpandEntityReferences(false);

在“Hello-Java-Sec”中，这两类漏洞通常会设计成简单的接口，让你直观地看到如何通过一个URL参数让服务器访问内部系统，或如何通过一段XML载荷读取服务器上的文件。

3. 搭建审计环境与工具链配置

工欲善其事，必先利其器。一个顺手的审计环境能极大提升效率。对于Java代码审计，环境搭建主要分为两部分：一是运行和调试“Hello-Java-Sec”靶场应用本身，二是配置辅助审计的代码分析工具。

3.1 靶场应用部署与运行

“Hello-Java-Sec”通常是一个标准的Maven或Gradle项目。第一步是获取源码，你可以从GitHub等开源平台找到它。使用IDEA或Eclipse这类IDE直接导入Maven项目是最简单的方式。导入后，IDE会自动下载依赖。

项目很可能是一个Spring Boot应用，那么运行它通常有两种方式：

直接运行主类：在IDE中找到标注了@SpringBootApplication的类，右键运行它的main方法。这是最方便的调试方式，可以随时打断点。
使用Maven命令：在项目根目录下打开终端，执行mvn spring-boot:run。这种方式更接近生产部署。

应用启动后，控制台会打印出访问地址，通常是http://localhost:8080。打开浏览器访问，你应该能看到一个简单的Web界面，列出了各种漏洞的入口链接。确保每个链接都能正常访问，这是后续审计的基础。

实操心得：在启动前，建议先检查项目的application.properties或application.yml配置文件，看看数据库连接等配置是否正确。有时靶场需要配合一个内存数据库（如H2）或MySQL运行，按照项目README的说明初始化数据库通常是必要步骤。我第一次跑的时候，就因为没初始化数据库，导致所有涉及数据库的漏洞例子都报500错误，排查了半天。

3.2 静态代码分析工具配置

单纯用肉眼阅读代码效率低下，我们需要工具来帮我们快速定位潜在风险点。这里推荐几个组合使用的工具：

IDE的全局搜索（Find in Path）：这是最基础也是最强大的工具。你可以搜索关键词如executeQuery、Runtime.exec、File(、readObject、DocumentBuilder等，快速找到所有相关代码位置。
Semgrep：这是一个开源的、基于模式的静态分析工具，对安全审计非常友好。它内置了许多针对不同语言的安全规则（包括Java）。你可以在项目根目录运行semgrep --config auto .，它会自动使用相关规则进行扫描，并输出疑似漏洞的位置和规则说明。这对于快速发现“低垂的果实”非常有效。
SpotBugs：这是一个经典的Java字节码静态分析工具，可以检测出空指针解引用、资源未关闭、不良实践等各类问题。其中也包含一个安全插件find-sec-bugs，专门用于发现安全漏洞模式。你可以将其集成到Maven构建中（在pom.xml中添加插件配置），每次编译后自动检查。
CodeQL：这是一个更高级的语义代码分析引擎。你可以为项目创建CodeQL数据库，然后编写或使用现成的查询来发现复杂的漏洞链。它的学习曲线较陡，但对于想深入做自动化审计的人来说是终极武器之一。对于“Hello-Java-Sec”学习，可以先从它的现成Java安全查询库开始用起。

我的个人工作流是：先用Semgrep快速扫一遍，得到一个初步的“可疑点”列表；然后用IDE打开这些点所在的文件，结合上下文进行人工确认和分析；对于复杂的逻辑，再使用IDE的调试功能，动态跟踪数据流。不要完全依赖工具，工具的结果是辅助，最终判断必须由人来做，因为工具会产生误报（把安全的代码报成漏洞）和漏报（没发现真正的漏洞）。

3.3 动态调试技巧

动态调试是理解漏洞触发流程的利器。以IDEA为例，在疑似存在漏洞的代码行左侧点击设置断点。然后，在浏览器中触发对应的漏洞接口（比如提交一个带有SQL注入Payload的表单）。当请求执行到断点处时，IDEA会暂停程序，此时你可以：

查看变量值：鼠标悬停在变量上，或在下方的“Variables”窗口查看所有局部变量和成员变量的当前值。这能让你清楚地看到用户输入是什么形态。
单步执行（Step Over/Into）：按F8（Step Over）逐行执行，按F7（Step Into）进入方法内部。这可以让你跟踪数据是如何被处理的。
计算表达式（Evaluate Expression）：你可以选中一段代码，按Alt+F8，动态计算它的结果，这对于理解复杂的字符串拼接或条件判断非常有用。

例如，在审计一个SQL注入点时，你可以在PreparedStatement设置参数的那一行（setString）打断点，观察传入的参数是否已经被污染。或者，在命令执行前，打断点查看最终要执行的命令字符串是什么。通过动态调试，抽象的代码逻辑变成了可视化的、一步步的执行过程，对新手理解漏洞成因有巨大帮助。

4. 从入口到漏洞：跟踪一个完整的SQL注入案例

现在，让我们把理论付诸实践，以“Hello-Java-Sec”中一个典型的SQL注入漏洞为例，完整走一遍审计流程。假设我们通过Semgrep扫描或简单的全局搜索，在UserController.java中发现了一段可疑代码。

4.1 定位漏洞代码

我们找到了一个处理用户登录的方法：

@PostMapping("/login") public String login(@RequestParam String username, @RequestParam String password, HttpSession session) { String sql = "SELECT id, username FROM users WHERE username = '" + username + "' AND password = '" + password + "'"; try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sql)) { if (rs.next()) { session.setAttribute("userId", rs.getInt("id")); return "redirect:/dashboard"; } else { return "login?error=true"; } } catch (SQLException e) { e.printStackTrace(); return "error"; } }

审计分析：一眼就能看出问题所在。第3行，username和password这两个直接从HTTP请求参数中获取的字符串，未经任何过滤，就直接通过+运算符拼接到了SQL语句中。这是一个非常经典的“字符串拼接式”SQL注入。攻击者可以在username字段输入admin'--（注意--是SQL中的注释符），这样拼接后的SQL就变成了：

SELECT id, username FROM users WHERE username = 'admin'--' AND password = 'anything'

--之后的内容被注释掉，攻击者就能在不知道密码的情况下，以admin用户身份登录。

4.2 构造与验证Payload

仅仅看到代码还不够，我们需要验证它确实可以被利用。我们启动应用，并打开浏览器开发者工具（F12）的“网络（Network）”选项卡。

观察正常请求：我们先在登录页输入一个错误的测试账号，比如test/123，点击登录。在“网络”选项卡中，我们会看到一个POST请求发送到了/login，其请求体（Payload）是username=test&password=123（可能是Form Data格式）。记住这个格式。
构造恶意请求：我们可以直接在这个失败的请求上右键，选择“编辑并重发（Edit and Resend）”。将username参数修改为我们的Payload：admin'--。注意，如果密码字段不能为空，可以随便填一个值，比如xxx。修改后，发送请求。
分析响应：如果漏洞存在，服务器可能会返回一个302重定向到/dashboard，或者直接在响应体中返回登录成功的页面内容。同时，查看Response Headers中的Set-Cookie字段，可能会设置新的会话ID，这表明我们成功创建了一个会话。

实操心得：在实际测试中，可能会遇到一些阻碍。比如，应用可能对请求参数做了全局的过滤或转义。这时，可以尝试多种Payload变体：
绕过引号：如果单引号被转义，可以尝试用\进行转义，或者利用数字型注入（如果参数是数字类型，可能不需要引号），例如id=1 OR 1=1。
注释符：除了--（后面通常要跟一个空格），还可以尝试#（MySQL）。有时需要URL编码，--是--%20，#是%23。
多语句执行：尝试在参数末尾加上;，然后接上DROP TABLE users之类的语句，看是否支持堆叠查询（取决于JDBC驱动和数据库配置，通常默认不支持）。在“Hello-Java-Sec”中，为了教学，它通常会设计成最容易被触发的形式，但尝试这些变体是很好的练习。

4.3 修复方案与代码改写

找到并验证了漏洞，下一步就是修复它。修复SQL注入的标准且唯一推荐的做法就是使用参数化查询（Prepared Statement）。

我们来重写上面的login方法：

@PostMapping("/login") public String login(@RequestParam String username, @RequestParam String password, HttpSession session) { // 使用参数化查询，SQL语句中的参数用?占位 String sql = "SELECT id, username FROM users WHERE username = ? AND password = ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement pstmt = conn.prepareStatement(sql)) { // 注意这里使用PreparedStatement // 为占位符设置参数值 pstmt.setString(1, username); pstmt.setString(2, password); try (ResultSet rs = pstmt.executeQuery()) { if (rs.next()) { session.setAttribute("userId", rs.getInt("id")); return "redirect:/dashboard"; } else { return "login?error=true"; } } } catch (SQLException e) { e.printStackTrace(); return "error"; } }

修复原理：PreparedStatement在创建时就将SQL语句的模板发送给数据库进行编译。后续的setString等方法，只是将参数值作为“数据”传递给这个已编译的模板。数据库能清晰地分辨哪些是SQL指令，哪些是数据，从而从根本上杜绝了将数据误解析为指令的可能性。即使username参数传入admin'--，它也会被当作一个完整的字符串值去和username字段比较，而不会改变SQL语句的结构。

重要提示：千万不要试图用字符串替换函数（如replace）过滤单引号等字符来“修复”SQL注入，这是徒劳且危险的。攻击者的绕过手法层出不穷（编码、嵌套、利用数据库特性等），只有参数化查询是治本之策。同样，在MyBatis等ORM框架中，应使用#{}语法（它会产生参数化查询），而避免使用${}语法（它会导致字符串拼接）。

5. 命令执行漏洞的深度挖掘与绕过

命令执行漏洞的危害性极高，因为它可能让攻击者在服务器上直接执行任意系统命令。在“Hello-Java-Sec”中，你可能会遇到一个简单的例子，比如一个“Ping工具”功能。

5.1 基础漏洞代码分析

假设找到如下代码：

@GetMapping("/ping") public String ping(@RequestParam String host) throws IOException { String cmd = "ping -c 4 " + host; // 假设是Linux/macOS系统 Process process = Runtime.getRuntime().exec(cmd); // ... 读取process的输入流并返回给前端 ... }

这段代码意图是让用户输入一个主机名或IP，服务器执行ping命令并返回结果。问题在于，host参数直接拼接到了命令字符串中。攻击者可以输入8.8.8.8; ls -la /，那么最终执行的命令就是：

ping -c 4 8.8.8.8; ls -la /

分号;在Unix shell中表示命令分隔符。于是，服务器在ping完之后，还会执行ls -la /，列出根目录下的所有文件。

5.2 命令分隔符与参数注入

除了分号;，常见的命令分隔符或注入点还包括：

&：后台执行，前一个命令完成后执行后一个。
&&：逻辑与，前一个命令成功才执行后一个。
|：管道符，将前一个命令的输出作为后一个命令的输入。
`（反引号）和$()：命令替换，先执行反引号或$()内的命令，将其输出替换到原位置。
换行符（\n）：在某些上下文中也能起到分隔命令的作用。

更危险的是参数注入。假设命令本身是固定的，但参数可控：

String[] cmd = {"sh", "-c", "echo Hello " + userInput};

攻击者输入World; cat /etc/passwd，那么sh -c后面的整个字符串就变成了echo Hello World; cat /etc/passwd，同样可以执行任意命令。这里的关键是sh -c，它会把后面的整个字符串当作一个shell脚本来解析，其中的特殊字符（空格、分号、引号等）都由shell来解释。

5.3 安全的命令执行实践

绝对安全的做法是避免执行包含用户输入的命令。如果业务必须执行系统命令，应遵循以下原则：

白名单校验：对用户输入进行严格的白名单过滤。例如，如果host参数预期是一个IP地址或主机名，就用正则表达式严格匹配其格式（如IPV4、IPV6、合法域名）。只允许通过白名单的字符。
```
if (!host.matches("^[a-zA-Z0-9.-]+$")) { // 一个非常简单的示例，实际需要更复杂的规则 return "Invalid hostname"; }
```
避免调用Shell：使用Runtime.exec(String[] cmdarray)的重载形式，而不是Runtime.exec(String command)。前者不会启动系统的shell（如/bin/sh或cmd.exe）来解释命令，而是直接将数组中的第一个元素作为可执行文件，后续元素作为独立的参数传递给它。这可以防止命令分隔符生效。
```
// 相对安全的方式 String[] cmd = {"ping", "-c", "4", host}; Process process = Runtime.getRuntime().exec(cmd);
```
即使host是8.8.8.8; ls，它也会被当作一个整体字符串作为ping命令的第四个参数。ping命令会试图去ping一个名为8.8.8.8; ls的主机，这通常会失败，但不会执行ls命令。但是，这并非绝对安全，如果参数本身的内容能改变命令行为（例如host是-c 1; ls，而某些命令的选项解析存在缺陷），仍可能存在风险。
最小权限原则：执行命令的Java进程应以尽可能低的系统权限运行。不要用root或管理员账户运行Java应用。
使用安全的替代API：对于网络探测（如ping），考虑使用Java原生的InetAddress.isReachable方法。对于文件操作，尽量使用Java的NIO API而非执行rm、cp等命令。

在审计时，看到Runtime.exec或ProcessBuilder，就要像看到Statement一样警惕。必须仔细审查其参数构造过程，确认用户输入是否影响了命令或参数，以及是否有可能被shell解析。

6. 文件上传漏洞的检测与利用链构造

文件上传功能如果处理不当，是获取服务器权限（俗称“拿shell”）的捷径。“Hello-Java-Sec”中肯定会包含这个经典漏洞。

6.1 典型的不安全代码模式

一个最简单的存在漏洞的上传Servlet可能长这样：

@PostMapping("/upload") public String handleFileUpload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return "File is empty"; } String fileName = file.getOriginalFilename(); // 直接使用原始文件名 File dest = new File("/tmp/uploads/" + fileName); // 路径拼接 file.transferTo(dest); // 保存文件 return "Upload success: " + fileName; }

这段代码存在多个问题：

使用原始文件名（getOriginalFilename()）：攻击者可以上传一个名为shell.jsp的文件。
路径拼接未做目录穿越检查：如果文件名是../../../webapps/ROOT/shell.jsp，文件可能被保存到Web应用的根目录下，从而可以通过URL直接访问。
未校验文件内容：仅凭文件名后缀判断文件类型是极不可靠的，攻击者可以伪造文件头。

6.2 绕过前端校验与MIME类型欺骗

很多应用会在前端用JavaScript校验文件后缀，但这形同虚设。攻击者可以直接用Burp Suite等工具拦截上传请求，修改filename字段和后缀名即可绕过。

更隐蔽的绕过是针对服务端的MIME类型检查。Spring的MultipartFile.getContentType()返回的是浏览器提供的Content-Type头，同样可以被篡改。攻击者可以将一个JSP文件的内容，在请求中将其Content-Type设置为image/jpeg。如果后端只检查这个字段，就会被绕过。

安全的做法是服务端校验文件魔数（Magic Number）。每种文件格式在文件开头都有特定的字节序列。例如，JPEG图片以FF D8 FF开头，PNG图片以89 50 4E 47开头。Java中可以通过读取文件的前几个字节来判断真实类型。

InputStream is = file.getInputStream(); byte[] header = new byte[4]; is.read(header); is.close(); // 判断header是否符合预期格式，例如PNG if (header[0] == (byte)0x89 && header[1] == 0x50 && header[2] == 0x4E && header[3] == 0x47) { // 可能是PNG } else { throw new IllegalArgumentException("Invalid file type"); }

6.3 安全的文件上传实现要点

一个相对安全的文件上传实现应包含以下步骤：

重命名文件：不要使用用户上传的文件名。使用随机生成的文件名（如UUID），并保留安全的扩展名（根据校验后的真实类型决定）。

String originalFilename = file.getOriginalFilename(); String fileExtension = getRealFileExtension(file); // 通过魔数获取真实扩展名 String savedFileName = UUID.randomUUID().toString() + "." + fileExtension;

限制上传目录：将文件保存在Web根目录之外。例如，保存在/var/app/uploads/，然后通过一个专门的、有权限控制的Controller来读取和提供这些文件（如/file/{id}）。绝对不要让上传目录具有执行脚本的权限。
校验文件大小和类型：在配置中限制最大文件大小。使用魔数校验文件真实类型，并建立白名单（如只允许jpg, png, pdf）。

防止目录穿越：对拼接后的完整路径进行规范化，并检查其是否仍在指定的基础目录内。

Path basePath = Paths.get("/var/app/uploads").toAbsolutePath().normalize(); Path destinationPath = basePath.resolve(savedFileName).normalize(); if (!destinationPath.startsWith(basePath)) { throw new IOException("Invalid file path."); } Files.copy(file.getInputStream(), destinationPath, StandardCopyOption.REPLACE_EXISTING);

设置文件系统权限：确保上传目录的权限设置正确，Java进程只有写入权限，没有执行权限。

审计文件上传功能时，要像剥洋葱一样，一层层检查这些防护措施是否到位。缺失任何一层，都可能被组合利用形成漏洞。

7. 反序列化漏洞的初步探索与Gadget链

Java反序列化漏洞因其危害巨大而备受关注。在“Hello-Java-Sec”中，你可能会遇到一个直接反序列化网络数据的端点。

7.1 一个简单的漏洞示例

@PostMapping("/deserialize") public void deserializeData(HttpServletRequest request) { try (ObjectInputStream ois = new ObjectInputStream(request.getInputStream())) { Object obj = ois.readObject(); // 危险！ // ... 处理obj ... } catch (Exception e) { e.printStackTrace(); } }

这段代码直接从HTTP请求体中读取字节流并进行反序列化。如果攻击者精心构造了一个恶意的序列化对象（Payload）发送过来，在readObject()时就会触发漏洞。

7.2 理解Gadget链

单纯的readObject()方法本身并不执行代码。漏洞的触发依赖于目标应用的Classpath（类路径）上是否存在一系列特殊的类库，这些类库中的类在反序列化时（在其readObject、hashCode、equals、toString等方法中）会执行一些危险操作，比如调用Runtime.exec()。攻击者通过精心构造一个对象图，将这些类像齿轮一样串联起来，形成一个从反序列化入口到最终危险操作（如命令执行）的调用链，这就是“Gadget链”。

最著名的Gadget链库是Apache Commons Collections（3.x版本）。如果应用引入了这个库的旧版本（如3.2.1），攻击者就可以利用其中的Transformer、InvokerTransformer、ChainedTransformer等类，构造出执行任意命令的链。其他常见的库还有Groovy、Spring、Fastjson、Jackson等，在特定版本和配置下都可能存在可用的Gadget。

7.3 审计与修复策略

审计入口点：全局搜索ObjectInputStream.readObject()、XMLDecoder.readObject、Yaml.load、JSON.parseObject（某些模式下）等方法的调用。检查其输入源是否来自网络、文件等不可信源。
检查依赖：使用mvn dependency:tree或gradle dependencies命令查看项目依赖。重点关注已知存在反序列化Gadget的库及其版本，例如commons-collections:commons-collections:3.2.1。
修复方案：
- 首选方案：禁用或替换：如果业务不需要Java原生序列化，彻底移除相关代码，换用JSON等安全格式。
- 输入过滤：如果必须使用，考虑在反序列化前对字节流进行验证或过滤，但这非常困难且容易绕过。
- 使用白名单：使用ObjectInputFilter（Java 9+）或第三方库（如SerialKiller）来限制反序列化时允许加载的类。这是相对有效的缓解措施，但需要精心维护白名单。
- 升级依赖：将已知存在Gadget的库升级到已修复的安全版本。但注意，新的Gadget链可能随时被发现，这不是一劳永逸的方法。

对于“Hello-Java-Sec”中的例子，理解其原理是关键：反序列化本身是一个强大的机制，但当它遇到来自外部的、不受控制的数据和Classpath中某些“危险”的类时，就变成了一个致命的漏洞。审计时，要同时关注“入口”和“可利用的库”。

8. 常见问题排查与实战技巧实录

在实际审计“Hello-Java-Sec”或类似项目时，你可能会遇到一些共性问题。这里记录一些我踩过的坑和总结的技巧。

8.1 环境问题导致漏洞无法复现

问题：按照说明启动项目后，访问漏洞页面却返回500错误或空白页。
排查：
1. 检查数据库：这是最常见的问题。很多漏洞（如SQL注入、存储型XSS）依赖数据库中的数据。查看项目README，是否要求你执行SQL脚本初始化数据库。检查application.properties中的数据库连接配置是否正确，数据库服务是否已启动。
2. 查看日志：这是定位问题的黄金手段。在IDE的控制台或日志文件中查找异常堆栈信息（StackTrace）。错误信息会明确指出是哪一行代码出了问题，是空指针、SQL异常还是类找不到。
3. 依赖下载失败：Maven或Gradle可能因为网络问题没有下载完所有依赖。尝试在项目根目录执行mvn clean compile或gradle build，看是否能成功编译。IDE通常也有“重新导入Maven项目”或“刷新Gradle项目”的选项。
4. 端口占用：默认的8080端口可能被其他程序占用。查看启动日志，或修改application.properties中的server.port配置。

8.2 工具扫描结果误报与漏报

问题：Semgrep或SpotBugs报告了一堆问题，但有些看起来不像漏洞；或者明明存在漏洞，工具却没扫出来。
处理：
- 对待误报：静态分析工具基于模式匹配，难免误报。例如，它可能将一段从固定配置文件读取数据再拼接SQL的代码也报为SQL注入。这时需要人工确认数据源是否真正用户可控。将误报的案例记录下来，有助于你未来更精准地判断。
- 对待漏报：工具规则库覆盖不全，或漏洞模式过于复杂（如跨多个类的数据流），都可能导致漏报。永远不要完全依赖工具。人工审计，尤其是对关键功能（登录、支付、文件上传、管理后台）的代码逐行审阅，是不可替代的。结合数据流分析（跟踪参数传递）和控制流分析（理解业务逻辑），才能发现深层漏洞。

8.3 动态调试时断点不生效

问题：在IDEA中打了断点，但发送请求时代码并没有停住。
排查：
1. 确保调试模式启动：如果是Spring Boot应用，确保你是通过调试模式（Debug）运行主类，而不是普通运行（Run）。IDEA工具栏上有一个虫子图标代表调试。
2. 检查代码版本：你正在查看的源代码版本，是否与正在运行的应用版本一致？尤其是在你修改了代码后，是否重新编译和部署了？可以尝试在代码中加一行System.out.println测试一下。
3. 断点类型：确保是行断点（红圈），而不是方法断点等其他类型。检查断点是否被禁用（红圈变灰）。
4. 请求是否到达：在Controller类的最开始方法入口处打一个断点，确认请求是否真的进入了你预期的代码路径。可能请求被拦截器（Interceptor）、过滤器（Filter）或全局异常处理器给拦截或转向了。

8.4 漏洞利用Payload构造心得

SQL注入：除了经典的' OR '1'='1，多尝试基于布尔的盲注和时间盲注的Payload，如' AND SLEEP(5)--，这有助于理解不同数据库的差异。使用sqlmap工具可以自动化这个过程，但学习阶段建议手动构造，加深理解。
命令执行：在Linux下，尝试用$(id)来替换执行命令并回显。如果无回显，可以尝试使用ping -c 10 127.0.0.1来制造时间延迟，判断命令是否执行（时间盲注）。也可以尝试将命令结果写入Web目录下的一个文件，然后通过Web访问该文件来读取输出。
文件上传：尝试双写后缀（shell.jsp.jpg）、大小写绕过（shell.Jsp）、在文件名末尾加空格或点（shell.jsp.，Windows可能会自动去除）、以及配合解析漏洞（如Apache的shell.jpg.php，如果配置不当可能被解析为php）。
XXE：除了读取文件，尝试使用http://协议来发起SSRF，探测内网端口和服务。Payload如：<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">。

审计“Hello-Java-Sec”这样的靶场，目的不是追求最炫酷的绕过技巧，而是建立对漏洞原理的扎实理解，并形成一套属于自己的、系统化的审计方法论。从信息收集（看项目结构、依赖），到静态扫描（工具辅助），再到动态验证（手动测试、调试），最后到修复建议，这是一个完整的闭环。把这个流程走通、走熟，你才算是真正踏入了Java代码审计的大门。

查看全文

http://www.jsqmd.com/news/1085524/