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

Java Web应用XSS防护终极指南：九大核心技巧构建纵深防御体系

news 2026/6/26 5:24:32

1. 项目概述：为什么Java开发者必须掌握XSS防护？

在Web应用开发领域，跨站脚本攻击（XSS）就像是一个潜伏在暗处的“幽灵”，它不直接攻击服务器，而是通过劫持用户的浏览器来作恶。作为一名有十多年经验的Java后端开发者，我见过太多因为对XSS防护掉以轻心而导致的严重安全事件：用户会话被窃取、网站页面被篡改、甚至通过钓鱼盗取用户敏感信息。尤其是在当前前后端分离、富客户端应用盛行的架构下，XSS的攻击面不仅没有缩小，反而变得更加复杂和隐蔽。Java作为企业级应用开发的中流砥柱，其生态中从古老的JSP到现代的Spring Boot，都面临着XSS的威胁。网上充斥着各种零散的防护技巧，但缺乏一个系统、深入且能直接应用于生产环境的“终极指南”。这篇文章，我将结合自己踩过的坑和实战经验，为你拆解九大核心防护技巧，从原理到落地，让你构建起固若金汤的Java Web应用防线。无论你是正在应对面试中的安全八股文，还是在实际开发中遇到了DVWA、Pikachu靶场里那样的XSS漏洞，或是正在为公司的关键业务系统做安全加固，这份指南都将提供清晰的路径和可复现的解决方案。

2. XSS攻击原理深度解析与分类

在讨论防护之前，我们必须彻底理解攻击是如何发生的。XSS的本质是“注入”，攻击者将恶意脚本代码“注入”到原本受信任的网页中，当其他用户浏览该页面时，嵌入的恶意脚本就会被执行。

2.1 反射型XSS：一次性的“钓鱼钩”

反射型XSS是最常见，也相对容易理解的一种。它的攻击流程可以概括为“诱导点击-服务器反射-浏览器执行”。

攻击链：攻击者精心构造一个包含恶意脚本的URL，例如http://vulnerable-site.com/search?keyword=<script>alert('XSS')</script>。
社会工程：通过邮件、即时消息等方式，诱骗受害者点击这个链接。
服务器反射：服务器接收到这个请求，未加过滤地将keyword参数值（即恶意脚本）嵌入到返回的HTML页面中。
客户端执行：受害者的浏览器接收到响应，将其作为正常页面的一部分解析并执行了其中的<script>标签。

注意：反射型XSS的数据流向是“浏览器 -> 服务器 -> 浏览器”，恶意脚本不会持久化存储在服务器上。DVWA靶场中的Low级别反射型XSS就是典型例子，它直接将输入回显，毫无防护。

2.2 存储型XSS：潜伏的“定时炸弹”

存储型XSS的危害性更大，因为它具有持久性。

攻击链：攻击者将恶意脚本提交到网站并进行存储，比如在论坛的帖子内容、用户评论、个人资料昵称等字段中写入<script>...</script>。
持久化存储：服务器将这些包含恶意脚本的内容存入数据库。
广泛传播：任何时候，只要其他用户浏览到包含这些恶意内容的页面（如查看那条帖子或评论），脚本就会被自动加载并执行。
危害升级：由于内容被持久化，所有访问者都会中招，非常适合用于挂马、蠕虫传播等。Pikachu靶场中的存储型XSS漏洞就模拟了这种场景。

2.3 DOM型XSS：纯前端的“密室作案”

DOM型XSS比较特殊，它不经过服务器端处理，完全发生在客户端的JavaScript执行环境中。

攻击链：攻击URL中携带恶意数据，例如http://example.com#<img src=1 onerror=alert('XSS')>。
客户端处理：页面加载后，前端的JavaScript代码（如使用location.hash,document.write,innerHTML等）从URL片段（hash）或其它客户端源（如本地存储）读取了该数据。
不安全操作：前端代码未经验证和转义，直接将数据拼接进HTML字符串或作为DOM属性赋值。
脚本执行：浏览器动态更新DOM时，将恶意字符串解析为可执行的HTML/JS元素并执行。

实操心得：区分存储/反射型与DOM型的关键，是看恶意数据是否“经过服务器端”。用浏览器开发者工具的Network面板查看响应，如果响应HTML里已经包含了恶意脚本，是前者；如果响应是干净的，但执行前端JS后页面被篡改，则是后者。这对排查漏洞来源至关重要。

3. 防护体系设计：纵深防御与核心思路

单一的防护手段很容易被绕过，有效的XSS防护必须是一个多层次、纵深防御的体系。我的思路是构建三道核心防线：

输入防线：严格的验证与过滤。在数据进入系统的第一时间就进行管控，遵循“最小权限原则”，只接受符合预期格式的数据。
输出防线：彻底的编码与转义。在数据离开服务器、即将渲染到不同上下文（HTML、JavaScript、CSS、URL）时，进行针对性的编码，这是最根本、最有效的措施。
客户端防线：内容安全策略与运行时保护。即使前两道防线有疏漏，最后一道浏览器端的策略也能有效遏制攻击的执行。

接下来，我将围绕这三大防线，详细拆解九大防护技巧。

4. 终极防护技巧一：输入验证与白名单过滤

很多人把“过滤”挂在嘴边，但错误的过滤（如黑名单）形同虚设。正确的姿势是白名单验证。

4.1 服务端数据校验：使用Jakarta Bean Validation

对于明确的格式要求，如邮箱、电话、数字范围，应在Controller层或Service层入口进行强校验。

// 使用 @NotBlank, @Email, @Pattern 等注解进行声明式验证 public class UserDTO { @NotBlank(message = "用户名不能为空") @Size(min = 2, max = 20, message = "用户名长度2-20位") private String username; @NotBlank @Email(message = "邮箱格式不正确") private String email; @Pattern(regexp = "^[\\u4e00-\\u9fa5a-zA-Z0-9_,.-]{1,50}$", message = "地址包含非法字符") private String address; } // 在Controller方法参数前添加 @Valid 注解触发校验

注意事项：正则表达式白名单的设计需要非常小心。例如上面的地址校验，明确允许了中英文、数字及常见标点，拒绝了尖括号、引号等可能用于构造脚本的字符。对于富文本等复杂场景，单纯的输入校验不够，必须结合输出编码。

4.2 处理富文本输入：使用JSoup进行HTML净化

用户提交的HTML内容（如文章详情、评论）是XSS的重灾区。绝不能简单转义所有尖括号（那会破坏格式），也不能使用黑名单（<script>标签有无数种变体）。必须使用专业的HTML净化库，如JSoup，它采用白名单机制。

import org.jsoup.Jsoup; import org.jsoup.safety.Safelist; public class HtmlSanitizer { // 定义一个相对宽松但安全的白名单，允许基本的文本格式 private static final Safelist CONTENT_SAFELIST = Safelist.relaxed() .addTags("div", "p", "br", "hr", "span") .addAttributes("a", "href", "title", "target") // 允许链接，但href会被校验 .addProtocols("a", "href", "http", "https", "mailto") // 限制协议 .addAttributes("img", "src", "alt", "title", "width", "height") .addProtocols("img", "src", "http", "https") .preserveRelativeLinks(true); // 保留相对链接 // 净化HTML内容 public static String sanitize(String dirtyHtml) { if (dirtyHtml == null || dirtyHtml.trim().isEmpty()) { return ""; } // Jsoup.clean 是核心方法，它会移除所有不在白名单内的标签和属性 String cleanHtml = Jsoup.clean(dirtyHtml, CONTENT_SAFELIST); // 进一步处理：确保所有标签和属性是小写的，闭合标签是规范的 cleanHtml = Jsoup.clean(cleanHtml, Safelist.none().addTags("html", "body")); return cleanHtml; } }

实操心得：白名单的配置需要根据业务需求精细调整。Safelist.relaxed()提供了一个基础，但你可能需要禁用style属性（防止CSS注入），或对href和src进行额外的URL安全校验（防止javascript:伪协议）。每次调整后，务必用XSS测试向量进行验证。

5. 终极防护技巧二：输出编码的上下文敏感性

这是防护的核心中的核心。XSS之所以发生，是因为数据被错误地解释为代码。输出编码的目的，就是确保数据始终被当作“数据”来处理。关键在于上下文：数据将要被放置的位置决定了它需要何种编码。

5.1 HTML主体编码：转义`< > & ' "`

当变量要插入到HTML标签之间（如<div>${content}</div>）或普通属性值（如<input value="${data}">）时，需要进行HTML实体编码。

推荐工具：Apache Commons Lang3 的StringEscapeUtils.escapeHtml4()或 Spring 的HtmlUtils.htmlEscape()。
原理：将危险字符转换为对应的HTML实体。
- <-><
- >->>
- &->&
- "->"
- '->'(或'，但前者兼容性更好)

在模板引擎中的应用：

Thymeleaf：默认自动进行HTML转义。<div th:text="${userInput}"></div>是安全的。如果确实需要输出原始HTML（风险极高），必须显式使用th:utext，并确保内容来源绝对可信或已净化。
FreeMarker/JSP：务必使用${userInput?html}或<c:out value="${userInput}" />。严禁直接使用${userInput}或<%= request.getParameter("input") %>。

5.2 HTML属性编码：警惕属性值未引号与事件处理器

属性值的编码比主体更复杂。

属性值必须用引号包裹：<input value=${unquoted}>是极度危险的，攻击者可以轻易闭合标签。必须写成<input value="${quoted}">。
属性值内部的编码：即使引用了，如果值中包含引号，也需要转义。例如，data值为" onmouseover="alert(1)，如果不转义，会变成<input value="" onmouseover="alert(1)">，依然构成XSS。因此，输出到属性值前，除了HTML编码，还需确保属性值周围的引号是匹配的。
避免用户可控数据进入事件处理器：如onclick,onload,onerror。永远不要让用户输入的内容直接成为on*属性的值。如果业务必须，需要极其严格的白名单过滤和JavaScript编码。

5.3 JavaScript上下文编码：防止脚本注入

当需要将服务器端数据嵌入到<script>标签或事件处理器中时，需要进行JavaScript编码。

错误示例：<script>var userData = '${userInput}';</script>。如果userInput是'; alert('xss'); //，脚本就会被注入。
正确做法：
1. 优先考虑：通过HTML元素的><div id="dataEl">// 服务器端 model.addAttribute("userJson", objectMapper.writeValueAsString(userInput));
```
<script> var userData = ${userJson}; // 注意，这里输出的是合法的JSON对象或字符串 </script>
```
  注意：确保userJson是一个完整的JSON值（如"safe string"或{"key":"value"}），直接拼接进JS上下文。Spring Boot默认的Jackson配置在将对象转为JSON时已处理了转义。

5.4 URL上下文编码：防范javascript:伪协议

当用户输入可能作为超链接的href或src时，必须验证协议。

威胁：<a href="${userUrl}">点击</a>，如果userUrl是javascript:alert(1)，点击就会执行。

防护：在输出前进行URL验证和净化。

import org.apache.commons.validator.routines.UrlValidator; public static String sanitizeUrl(String url) { String[] allowedSchemes = {"http", "https", "mailto", "ftp"}; UrlValidator validator = new UrlValidator(allowedSchemes); if (validator.isValid(url)) { return url; } else { // 返回一个安全的默认值或空字符串，绝不可返回原始输入 return "javascript:void(0);"; // 或 return "#"; } }

6. 终极防护技巧三：内容安全策略（CSP）部署实战

CSP是一个强大的浏览器安全特性，它通过白名单机制告诉浏览器哪些外部资源（脚本、样式、图片等）可以加载和执行，是缓解XSS的终极利器。即使攻击者成功注入了脚本，如果该脚本的来源不在白名单内，浏览器也会拒绝执行。

6.1 CSP策略配置详解

通过HTTP响应头Content-Security-Policy来部署。一个相对严格但通用的策略如下：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://*.imagehost.com; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self';

default-src 'self'：默认策略，所有未指定的资源类型都只允许从当前域名加载。
script-src 'self' https://trusted.cdn.com：脚本只允许来自本域和指定的可信CDN。特别注意：避免使用'unsafe-inline'，它会允许内联脚本（包括XSS注入的），使CSP防护大打折扣。如果必须使用内联脚本，可以采用nonce或hash机制。
style-src 'self' 'unsafe-inline'：样式允许本域和内联。内联样式风险相对较低，通常可以放宽。
img-src：定义图片源。
frame-ancestors 'none'：禁止页面被嵌套（防点击劫持）。
base-uri 'self'：限制<base>标签的URL，防止相对路径劫持。

6.2 在Spring Boot/Spring Security中配置CSP

最方便的方式是集成Spring Security。

import org.springframework.context.annotation.Bean; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.web.SecurityFilterChain; import static org.springframework.security.config.Customizer.withDefaults; @Configuration public class SecurityConfig { @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http // ... 其他配置（如登录、授权） .headers(headers -> headers .contentSecurityPolicy(csp -> csp .policyDirectives("default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://*.example-cdn.com;") ) .frameOptions(frame -> frame.deny()) // 配合 frame-ancestors .xssProtection(xss -> xss.headerValue(XXssProtectionHeaderWriter.HeaderValue.ENABLED_MODE_BLOCK)) ); return http.build(); } }

6.3 CSP报告与监控

初始部署CSP时，可以使用Content-Security-Policy-Report-Only头，只报告违规而不阻塞，观察日志以调整策略。

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;

在服务器端设置一个端点/csp-report-endpoint来接收浏览器发送的JSON格式违规报告，进行分析和策略优化。

踩坑实录：第一次上CSP时，我们直接用了严格策略，导致网站大量第三方统计脚本、字体图标和样式失效，页面布局混乱。后来通过Report-Only模式运行了一周，分析报告日志，逐步将必要的第三方域名加入白名单，才平稳上线。切记，CSP的部署是一个渐进、迭代的过程。

7. 终极防护技巧四：安全的Cookie设置

通过XSS窃取用户的会话Cookie（如JSESSIONID）是攻击者的主要目标之一。通过设置Cookie属性，可以极大增加窃取难度。

7.1 HttpOnly属性：阻断JavaScript访问

这是最重要的属性。设置了HttpOnly的Cookie，JavaScript的document.cookieAPI将无法读取它。

在Spring Boot中配置：

# application.yml server: servlet: session: cookie: http-only: true secure: true # 建议同时开启，见下文

对于自定义的Cookie：

Cookie cookie = new Cookie("auth_token", token); cookie.setHttpOnly(true); cookie.setSecure(true); // 仅在HTTPS下传输 cookie.setPath("/"); response.addCookie(cookie);

7.2 Secure属性与SameSite属性

Secure：Cookie只能通过HTTPS协议传输。防止在明文HTTP连接中被窃听。生产环境必须开启。
SameSite：控制Cookie在跨站请求中是否被发送。有效防御CSRF和部分XSS。
- Strict：最严格，完全禁止跨站发送Cookie。
- Lax：（现代浏览器默认值）允许部分安全的跨站请求（如导航链接）携带Cookie，阻止来自跨站的危险请求（如表单POST、iframe加载）。
- None：允许跨站发送，但必须同时设置Secure。

Spring Boot 2.6+ 配置SameSite：

server: servlet: session: cookie: same-site: lax # 或 strict

8. 终极防护技巧五：响应头安全加固

除了CSP，其他HTTP响应头也能提供额外的防护层。

8.1 X-XSS-Protection（已过时但仍有价值）

这个头用于启用（或禁用）浏览器内置的XSS过滤器。虽然现代浏览器已逐步废弃它（转向CSP），但对于旧版浏览器仍有意义。

X-XSS-Protection: 1; mode=block

1：启用过滤器。
mode=block：如果检测到XSS攻击，浏览器将阻止页面渲染，而不是尝试清理。

在Spring Security中，如前面示例，可以通过.xssProtection()配置。

8.2 X-Content-Type-Options

阻止浏览器进行MIME类型嗅探。强制浏览器遵守Content-Type头中声明的类型，防止将文本文件当作HTML或JS执行。

X-Content-Type-Options: nosniff

Spring Security默认会添加此头。

8.3 X-Frame-Options / Frame-Ancestors

防止页面被嵌入到<frame>,<iframe>,<embed>,<object>中，用于防御点击劫持。

X-Frame-Options: DENY

或（CSP的frame-ancestors指令更灵活，优先级更高）

Content-Security-Policy: ...; frame-ancestors 'none';

9. 终极防护技巧六：前端框架的自动防护与注意事项

现代前端框架如React、Vue、Angular在默认情况下提供了一定的XSS防护。

9.1 React的JSX自动转义

React在渲染JSX表达式{userInput}到DOM前，会自动对字符串进行转义。这意味着，在花括号中直接插入HTML字符串是安全的，它会被当作纯文本显示。

// 安全：`<script>alert('xss')</script>` 会被转义显示为文本 const safeElement = <div>{userInput}</div>;

危险操作：使用dangerouslySetInnerHTML属性。这个属性名已经足够警示。除非你100%确信内容安全（如来自后端已净化的富文本），否则绝对不要使用。

// 危险！仅在内容已由后端JSoup等工具净化后使用 const riskyElement = <div dangerouslySetInnerHTML={{__html: sanitizedHtml}} />;

9.2 Vue的文本插值与v-html指令

Vue的模板语法（{{ }}）和属性绑定（v-bind）也会自动进行HTML转义。

<!-- 安全：会被转义 --> <p>{{ userInput }}</p>

类似于React，Vue提供了v-html指令来输出原始HTML，使用时必须确保内容绝对安全。

<!-- 危险！需确保htmlContent已净化 --> <div v-html="htmlContent"></div>

核心原则：无论使用何种框架，永远不要将用户提供的、未经后端严格净化的数据，通过dangerouslySetInnerHTML或v-html这样的通道直接插入DOM。框架的自动转义只保护了默认的插值方式。

10. 终极防护技巧七：依赖库安全扫描与更新

你的应用安全不仅取决于你的代码，还取决于你引入的数百个第三方库（如Apache Commons、Jackson、各种Connector）。这些库中可能存在已知的安全漏洞（CVE）。

10.1 使用OWASP Dependency-Check

将其集成到Maven或Gradle构建流程中，在编译时自动检查依赖库的已知漏洞。

<!-- Maven pom.xml 示例 --> <plugin> <groupId>org.owasp</groupId> <artifactId>dependency-check-maven</artifactId> <version>8.4.2</version> <executions> <execution> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin>

运行mvn verify或mvn dependency-check:check，它会生成报告，列出存在漏洞的依赖及对应的CVE编号和严重等级。

10.2 定期更新与漏洞监控

定期执行扫描：至少每季度或每次重大发布前执行一次全面扫描。
关注安全公告：订阅关键依赖库（如Spring、Apache、Log4j2）的安全邮件列表或GitHub发布页。
使用最新稳定版：在可控范围内，尽量将依赖升级到已知修复了安全漏洞的版本。升级前需在测试环境充分验证兼容性。

11. 终极防护技巧八：安全编码规范与代码审计

技术手段再强，也抵不过开发人员的一个疏忽。建立并执行安全编码规范至关重要。

11.1 制定团队安全编码清单

将本文提到的防护点转化为团队Checklist：

[ ] 所有用户输入是否都经过验证（类型、长度、格式、范围）？
[ ] 输出到HTML时，是否使用了正确的上下文编码（Thymeleaf的th:text， FreeMarker的?html）？
[ ] 是否绝对避免了在JSP/模板中使用<%= %>或${}直接输出未编码变量？
[ ] 富文本处理是否使用了JSoup等白名单净化库？
[ ] 动态构建的SQL是否使用预编译语句（MyBatis#{}, JPA参数化查询），杜绝拼接？
[ ] Cookie是否设置了HttpOnly和Secure？
[ ] 响应头是否配置了CSP、X-Content-Type-Options等？
[ ] 是否禁用了不必要的HTTP方法（如TRACE）？

11.2 集成静态代码分析工具（SAST）

在CI/CD流水线中集成工具，自动检测代码中的安全漏洞模式。

SonarQube：配置安全规则集，持续扫描代码质量与安全。
SpotBugs（FindBugs的继任者）：配合find-sec-bugs插件，可以检测出潜在的XSS、SQL注入等漏洞模式。
IDE插件：在开发阶段就获得实时反馈，如 SonarLint。

12. 终极防护技巧九：自动化测试与漏洞演练

防护措施是否真的有效？需要通过测试来验证。

12.1 自动化安全测试集成

OWASP ZAP (Zed Attack Proxy)：可以集成到CI流水线中，对正在运行的应用进行自动化的主动扫描，模拟攻击者行为，发现XSS、SQL注入等漏洞。

针对性的单元/集成测试：编写测试用例，模拟攻击向量，验证你的防护逻辑。

@Test public void testHtmlEscapeInController() { String maliciousInput = "<script>alert('xss')</script>"; mockMvc.perform(get("/api/data").param("input", maliciousInput)) .andExpect(status().isOk()) .andExpect(content().string(not(containsString("<script>")))) // 断言响应中不包含原始脚本标签 .andExpect(content().string(containsString("&lt;script&gt;"))); // 断言响应中包含转义后的实体 }

12.2 定期进行漏洞演练与渗透测试

使用靶场自我训练：定期在DVWA、Pikachu、WebGoat等靶场中练习攻击手法，理解攻击者的思维，从而更好地设计防御。
聘请专业团队进行渗透测试：每年至少进行一次由外部安全专家进行的黑盒/白盒渗透测试，他们能发现内部人员可能忽视的盲点。
建立漏洞响应流程：一旦发现漏洞，应有明确的流程进行应急响应、修复、验证和复盘，形成安全闭环。

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

在实际开发和运维中，你会遇到各种各样奇怪的问题。这里记录几个我踩过的坑和解决方法。

13.1 富文本编辑器内容显示异常

问题：用户从Word复制内容到富文本编辑器后提交，前端显示时格式错乱，图片不显示。排查：

检查后端净化逻辑。JSoup的Safelist.relaxed()可能过滤了Word生成的一些特殊样式标签（如o:p,w:前缀的标签）或属性。
检查CSP策略。如果图片使用了data:URL或特定CDN，需要确保img-src指令包含了data:和对应的CDN域名。
检查前端v-html或dangerouslySetInnerHTML绑定的变量，确认接收的是后端净化后的完整HTML字符串，而不是被意外截断或转义了的字符串。解决：适当放宽JSoup白名单，添加必要的标签和属性前缀。同时，在前端富文本编辑器初始化时，配置其粘贴过滤规则，在源头减少不必要的样式。

13.2 CSP策略导致第三方资源加载失败

问题：部署CSP后，网站上的Google Analytics统计代码、字体图标（Font Awesome）、地图SDK等无法加载。排查：

打开浏览器开发者工具的Console面板，查看具体的CSP违规报告。报告会明确指出是script-src、style-src还是font-src违反了策略，以及被阻止的资源URL。
分析这些资源的来源域名。解决：将必需的、可信的第三方域名添加到CSP策略的相应指令中。例如，添加https://www.google-analytics.com到script-src。切忌为了方便直接添加*或'unsafe-inline'。

13.3 JSON接口返回数据被误转义

问题：某个返回JSON的API，前端解析时发现字符串中的HTML特殊字符被转义了（如&变成了&）。排查：

检查后端Controller。是否错误地使用了针对HTML的转义方法处理了要返回的JSON字符串？
检查消息转换器。Spring Boot默认使用Jackson，它会在序列化字符串时正确处理特殊字符（如引号、反斜杠），但不会转义HTML实体。问题可能出在自定义的拦截器或过滤器对响应体做了全局处理。解决：确保返回纯JSON数据的接口，其响应内容类型为application/json，并且不要经过HTML转义处理器。检查是否有类似CharacterEncodingFilter或自定义的ResponseBodyAdvice做了不必要的处理。

13.4 在URL参数中传递HTML内容导致乱码

问题：需要将一段HTML代码片段通过URL参数传递，但接收方解码后内容混乱。排查与解决：

绝对不要直接传递：URL有长度限制，且特殊字符需要编码。HTML中的&,?,#,%等字符在URL中有特殊含义。
正确做法：
- 方案A（推荐）：将HTML内容存储在服务器（如数据库、缓存），只传递一个唯一ID。
- 方案B（必须传递时）： a. 前端使用encodeURIComponent()对HTML字符串进行编码。 b. 后端使用URLDecoder.decode(param, "UTF-8")解码。 c.关键：解码后，必须将其视为纯文本或不信任的输入，在输出到页面时，根据上下文（很可能是HTML主体）进行HTML实体编码。切勿解码后直接输出。