Java 安全编码实践：注入、反序列化与依赖漏洞的系统性防护

这篇文章不是要重复罗列安全原则，而是想从工程实践的角度，拆解在Java开发中，如何围绕“注入”、“反序列化”和“依赖漏洞”这三个高频且危害巨大的领域，构建一套从代码编写、CI/CD流程到运行时监控的立体防护网。

注入攻击：不止是SQL，防御核心在于“语境”

提到注入，很多人第一反应是SQL注入。这没错，但它只是冰山一角。在Java Web应用中，注入可能发生在SQL、操作系统命令、LDAP查询、甚至表达式语言（如SpEL、OGNL）的解析过程中。防御的关键，是理解数据在不同“语境”（Context）下的安全处理方式。

SQL注入：告别字符串拼接，拥抱参数化

最经典的场景。攻击者通过构造特殊的输入，改变原有SQL语句的逻辑。很多团队知道要用PreparedStatement，但在复杂的动态查询场景，或者使用ORM框架时，仍然会不小心踩坑。

// 危险：字符串拼接
String sql = "SELECT * FROM users WHERE username = '" + username + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

// 安全：参数化查询
String sql = "SELECT * FROM users WHERE username = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, username);
ResultSet rs = pstmt.executeQuery();

关键在于，参数化查询将代码（SQL结构）和数据（用户输入）分离，数据库驱动会确保输入被当作纯数据处理。对于MyBatis，务必使用#{param}而不是${param}；在JPA或Hibernate中，优先使用命名参数或位置参数，避免拼接HQL/JPQL字符串。

XSS与输出编码：没有“万能过滤”，只有“精准编码”

另一个常见误区是试图在输入层过滤所有“危险字符”来防御XSS。这几乎不可能，因为同一段数据<script>在HTML正文、HTML属性、JavaScript代码块或URL中的危险性和编码方式完全不同。正确的策略是在输出时，根据数据将要被放置的上下文进行编码。

例如，使用OWASP Java Encoder库：

import org.owasp.encoder.Encode;

String safeForHtmlBody = Encode.forHtml(userInput); // 用于<div>内容
String safeForHtmlAttr = Encode.forHtmlAttribute(userInput); // 用于 id="value"
String safeForJavaScript = Encode.forJavaScript(userInput); // 用于JS字符串

现代模板引擎如Thymeleaf的th:text、JSP的<c:out>默认会进行HTML转义，但如果你直接使用response.getWriter().write()或是在JavaScript中动态拼接HTML，就必须手动处理。

表达式注入：框架便利性背后的陷阱

Spring的SpEL表达式功能强大，但也可能成为注入点，如果表达式内容来自用户可控的输入。

// 危险：动态解析用户可控的表达式
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression(userControlledString);
String result = exp.getValue(String.class);

// 安全做法：避免直接解析不可信字符串，或使用更安全的评估上下文。

这类问题更隐蔽，需要审计代码时特别关注那些接收字符串并执行动态解析的API。

反序列化：从“功能开关”到“攻击武器”

Java原生序列化机制（ObjectInputStream/ObjectOutputStream）设计之初并未考虑复杂的安全威胁。一个恶意的字节流，可以触发一系列精心构造的“gadget chains”，最终导致远程代码执行（RCE），历史上的Fastjson、Apache Commons Collections等漏洞都与此相关。

默认禁用与白名单控制

最根本的防护是避免使用Java原生序列化进行跨信任边界的数据传输。对于RPC、缓存、会话存储，优先考虑JSON（Jackson/Gson）、Protobuf、Kryo（需谨慎配置）等更安全的格式。

如果业务上无法避免（例如处理遗留协议），则必须实施严格的白名单控制。从JDK 9开始，可以通过JVM参数设置全局过滤器，更细粒度的方式是自定义ObjectInputStream。

public class SafeObjectInputStream extends ObjectInputStream {
    private static final Set<String> ALLOWED_CLASSES = Set.of(
        "com.example.dto.UserInfo",
        "java.util.ArrayList",
        "java.lang.String"
    );

    public SafeObjectInputStream(InputStream in) throws IOException {
        super(in);
    }

    @Override
    protected Class<?> resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException {
        String className = desc.getName();
        if (!ALLOWED_CLASSES.contains(className)) {
            throw new InvalidClassException("Unauthorized deserialization attempt for class: ", className);
        }
        return super.resolveClass(desc);
    }
}

防御反序列化DoS攻击

除了RCE，反序列化还可能被用于拒绝服务（DoS）攻击，例如通过构造深度嵌套的对象图导致栈溢出，或创建超大数组耗尽内存。可以通过JDK的序列化过滤器来限制资源消耗。

// JVM启动参数示例，限制反序列化行为
-Djdk.serialFilter=maxdepth=5;maxrefs=1000;maxarray=100000;!*

这条规则限制了对象图最大深度为5，最大引用数为1000，数组最大长度为100000，并且末尾的!*表示默认拒绝所有类，必须显式允许。

第三方依赖：看不见的防线缺口

现代Java应用严重依赖开源组件，一个脆弱的间接依赖就可能让所有安全努力付诸东流。Log4j2的漏洞就是最深刻的教训。

持续性的依赖管理

安全防护不能是“一次性”的。需要建立持续的依赖管理流程：

1. 清单管理：使用mvn dependency:tree或Gradle的依赖报告，清晰掌握项目所有直接和间接依赖。
2. 漏洞扫描：将OWASP Dependency-Check、Snyk或GitHub Dependabot集成到CI/CD流水线中，每次构建都自动检查已知漏洞。
3. 及时升级：建立机制，定期评估和升级依赖版本，特别是涉及安全补丁的版本。

最小权限与沙箱思考

即使使用了有漏洞的组件，也可以通过环境限制其危害。思考：这个组件真的需要网络访问权限吗？它需要文件系统的写权限吗？在容器化部署时，可以通过Seccomp、AppArmor等策略进行约束。在代码层面，对于特别危险的操作（如执行命令、反射调用），可以考虑启用Java安全管理器（SecurityManager）进行细粒度的权限检查。

构建系统性的防护体系

单一的技术点防护是不够的，安全需要融入软件开发生命周期（SDLC）。

对于开发团队，建议将安全活动“左移”：

• 在代码评审清单中加入安全项（如：SQL是否参数化？反序列化是否有白名单？新引入的依赖是否经过审查？）。
• 在CI流水线中设置安全门禁，如果SAST或依赖扫描发现高危漏洞，则阻断构建。
• 定期进行安全培训，让开发者理解漏洞原理而不仅仅是记住规则。

写在最后：安全是一种习惯

Java应用的安全防护，特别是应对注入、反序列化和依赖漏洞，没有一劳永逸的银弹。它依赖于对底层机制的理解（比如知道PreparedStatement如何工作）、对框架特性的清醒认识（知道${}和#{}的区别），以及将安全检查固化为团队开发流程的一部分。

最有效的安全，是让安全的实践变得像写单元测试一样自然。从今天开始，检查你的项目里是否还有拼接的SQL，审视你的反序列化逻辑是否对外暴露，并运行一次依赖漏洞扫描。这些看似微小的步骤，正是构建稳固应用基座的开始。