如果你是一名Java后端开发者，看到“jQuery XSS漏洞”这个标题，可能会下意识地想：“这难道不是前端的问题吗？”这种想法很普遍，但也是一个常见的误区。事实上，当Java服务端直接拼接 HTML 片段并返回给前端，而前端又恰好使用了特定版本的 jQuery 进行动态渲染时，后端的 Java 代码就成了“帮凶”。攻击者注入的恶意载荷，正是通过后端 API 这个“合法通道”进入前端的。

本文将站在 Java 后端开发 的视角，深入剖析 jQuery 漏洞的根本原理，并提供一套完整的后端纵深防御方案。

一、根源：一个源于 Java 后端的场景还原

你以为安全的数据，可能正在被前端“出卖”。我们先来看一个典型的危险场景。

1.1 后端 Java 代码（存在漏洞）

java

@RestController
public class SearchController {
    @GetMapping("/search")
    public String search(@RequestParam String kw) {
        // 后端只做了简单的业务处理，直接将参数进行 HTML 拼接返回
        return "<div class='result'>您搜索的关键词是：" + kw + "</div>";
    }
}

1.2 前端 jQuery 代码

javascript

$.get("/search?kw=" + userInput, function(data){
    // 直接将后端返回的 HTML 字符串 append 到页面上
    $("#content").html(data); 
});

在这个过程中，如果用户输入了恶意代码，后端直接拼接后返回，前端 $("#content").html(unsafeData) 则如同打开了潘多拉魔盒。jQuery 在内部处理 HTML 字符串时，其正则匹配逻辑存在缺陷，导致恶意代码被执行。

二、真相：jQuery 的两个核心高危漏洞 (CVE)

根据多个安全公告和 CVE 记录，广泛使用的 jQuery 低版本存在两个典型的 XSS 漏洞 。

2.1 XSS 漏洞一：DOM 操作处理缺陷 (CVE-2020-11022 / CVE-2020-11023)

• 影响版本：jQuery 1.x 至 3.4.x

• 原理：在 jQuery 3.5.0 之前，当使用 .html()、.append() 等方法处理 HTML 字符串时，jQuery 试图通过正则表达式（htmlPrefilter 方法）来修正自闭合标签和处理<option>标签。但这个正则存在逻辑缺陷，攻击者可以构造恶意的 HTML 字符串，绕过清理机制，从而执行任意 JavaScript 代码 。

2.2 XSS 漏洞二：Ajax 跨域脚本执行 (CVE-2015-9251)

• 影响版本：jQuery < 3.0.0

• 原理：这是一个较为隐蔽的漏洞。当 jQuery 发起跨域 Ajax 请求且未显式指定 dataType: "text" 时，如果服务器返回的 Content-Type 是 text/javascript，jQuery 会自动将返回内容当作脚本执行。配合 JSONP 接口的误用，可能造成 XSS 攻击 。

三、后端突围：不止是升级版本，更是架构重构

安全界有一句名言：“永远不要信任用户输入。”对于 Java 后端而言，这意味着我们绝对不能信任任何即将输出到前端的数据。在后端处理好数据安全，远比要求所有用户升级浏览器或等待前端修复版本来得更有效且更彻底。

3.1 必杀技：严格输出编码（HTML 实体转义）

这是抵御 XSS 最有效、成本最低的手段。其核心思想是：后端在输出数据时，将 HTML 中的特殊字符（如 <、>、"、' 等）转换为对应的 HTML 实体（如 <），这样浏览器在解析时，它们就只是普通的文本字符，而不会被当作代码执行。

错误做法：直接拼接

java

// 这样做极其危险
return "" + userInput;

正确做法：使用 OWASP Java Encoder

OWASP 的 Java Encoder 项目提供了一套专门针对不同上下文的编码方法 。

1. 引入依赖 (Maven)：

xml

<dependency>
    <groupId>org.owasp.encoder</groupId>
    <artifactId>encoder</artifactId>
    <version>1.2.3</version>
</dependency>

1. 代码实现：

java

import org.owasp.encoder.Encode;

@GetMapping("/safe-search")
public String safeSearch(@RequestParam String kw) {
    // 对输出到 HTML 正文的内容进行编码
    String safeKw = Encode.forHtml(kw);
    return "<div>结果是：" + safeKw + "</div>";
}

3.2 物理隔离：放弃拼凑 HTML，拥抱 JSON

将前后端进行更彻底的解耦。现代 Java 开发（如使用 React、Vue 或移动端应用时）通常采用纯 JSON 数据交互。

重构方案：

1. 后端只提供 RESTful API：返回 JSON 或 XML 纯数据，而不是 HTML 片段。

2. 前端负责渲染：前端框架通过 .text() 方法或模板引擎的文本插值（而非 v-html）来设置内容，这能天然防止 XSS。

java

@GetMapping("/safe-json")
public Map searchJson(@RequestParam String kw) {
    // 后端只负责返回数据，不涉及 HTML 结构
    return Collections.singletonMap("keyword", kw);
}

说明：即使是返回 JSON，如果数据中包含 <script> 标签，前端若使用 innerHTML 或未转义的插值渲染，仍会触发 XSS。因此后端建议对 JSON 中的文本字段也做一次 forHtml 编码，提供“纵深防御”。

3.3 架构防御：Filter 自动过滤

在全站范围内部署一个 XssFilter，它能自动清洗所有请求参数，从根源上杜绝恶意数据进入业务逻辑层和数据库 。

核心代码示例

java

public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper {
    public XssHttpServletRequestWrapper(HttpServletRequest request) {
        super(request);
    }

    @Override
    public String[] getParameterValues(String name) {
        String[] values = super.getParameterValues(name);
        if (values == null) return null;
        
        String[] encodedValues = new String[values.length];
        for (int i = 0; i < values.length; i++) {
            // 清洗：移除 script 标签或进行 HTML 转义
            encodedValues[i] = cleanXss(values[i]); 
        }
        return encodedValues;
    }
    
    private String cleanXss(String value) {
        // 可以使用 Jsoup 或 Owasp Java Html Sanitizer
        return Jsoup.clean(value, Whitelist.basic());
    }
}

然后在 web.xml 或 Spring Boot 配置中注册该 Filter，使其拦截所有请求。

策略方案	核心原理	适用场景
严格输出编码	输出时将特殊字符转为HTML实体	所有场景，最推荐的基础防御
返回JSON数据	前后端解耦，数据与渲染分离	现代Web应用、移动端API
Filter自动过滤	请求入口统一清洗参数	全站快速加固，遗留系统改造

3.4 补充边界防御：CSP 与 Cookie 安全

除了上述主动编码策略，还可以增加两道边界防守。

1. 内容安全策略 (CSP)：在 Java 响应头中设置 CSP，即使 XSS 被触发，也能极大限制其危害（如禁止向不可信域名发请求）。

java

@Component
public class SecurityHeaderFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        HttpServletResponse response = (HttpServletResponse) res;
        // 只允许同源资源，禁止执行内联脚本（可有效防范 XSS）
        response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'");
        chain.doFilter(req, res);
    }
}

2. Cookie 标记 HttpOnly：确保登录认证的 Cookie 标记为 HttpOnly，让恶意脚本无法通过 document.cookie 窃取用户 Session，阻断钓鱼后的盗号链。

java

// Spring Boot 配置示例
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true  // 仅在 HTTPS 下传输

四、总结：构建后端防御体系

1. 主动编码：将 Owasp Java Encoder 作为 Java Web 开发的标配工具，对任何输出到 HTML 的变量进行编码。

2. 升级依赖：检查项目中的 webjars 或静态资源引入，确保 jQuery 版本已升级至 3.5.0 或更高版本，从源头修复已知漏洞 。

3. 架构转型：避免后端 PrintWriter 直接拼接输出 HTML，转而使用 RESTful API + JSON 的交互模式，并配合前端框架的文本插值机制 。

4. 纵深防御：利用 Filter 清洗输入，利用 CSP 限制执行，利用 HttpOnly 保护凭证。

5. 自动化检测：在 CI/CD 流程中加入 Semgrep 等静态代码扫描工具，自动检查 JSP 中是否缺少 escapeXml 或是否存在直接输出流的行为 。

对于 Java 后端来说，防御 XSS 的核心原则是：后端永不信任前端传来的任何字符串，并且永远不在不编码的情况下将其输出回前端。这不仅仅是修复一个 jQuery 漏洞，更是建立一种成熟的安全开发生命周期思维。