Java后端安全实战：SQL注入与XSS攻击的防御体系构建

1. 项目概述：为什么后端安全是Java开发的“必修课”

干了十多年Java后端，我见过太多因为安全漏洞导致的“惨案”。一个精心设计的业务系统，可能就因为一个不起眼的SQL拼接，或者一个没做转义的用户输入，一夜之间数据被拖库、用户信息被泄露，甚至服务器沦为“肉鸡”。这绝不是危言耸听。今天，我们就来聊聊Java后端开发中最常见、也最危险的两大安全漏洞：SQL注入和XSS攻击。这不仅仅是面试八股文里的考点，更是每个一线开发者必须刻在骨子里的防御本能。

简单来说，SQL注入就是攻击者通过构造特殊的输入，欺骗后端数据库执行非预期的恶意SQL命令。而XSS（跨站脚本攻击）则是攻击者将恶意脚本注入到网页中，当其他用户浏览时，脚本就会在其浏览器中执行。这两者，一个直捣数据存储的核心——数据库，一个威胁数据展示的终端——用户浏览器，构成了Web应用安全最基础的攻防战线。对于Java开发者而言，掌握防御这两者的“最佳实践”，不是“加分项”，而是“及格线”。无论你是刚入行的新手，还是在维护一个成熟的老系统，这篇文章里提到的思路、代码和踩过的坑，都值得你仔细琢磨。

2. 核心威胁深度解析：SQL注入与XSS的攻击原理

在动手写防御代码之前，我们必须先搞清楚敌人是怎么进攻的。知其然，更要知其所以然，这样你写的每一行防御代码才会有灵魂。

2.1 SQL注入：当用户输入变成了数据库命令

SQL注入的本质，是“数据”和“代码”的混淆。在动态拼接SQL语句时，如果未对用户输入进行严格的区分处理，攻击者就能让输入数据“越界”，成为SQL语法的一部分。

一个经典的错误示范：

String userId = request.getParameter(“id”); // 用户输入
String sql = “SELECT * FROM users WHERE id = ‘“ + userId + “’”;
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

看起来没问题？如果用户输入的 id 是 1 ，那么SQL是 SELECT * FROM users WHERE id = ‘1’ 。但如果攻击者输入的是 1‘ OR ’1‘=’1 呢？拼接后的SQL就变成了：

SELECT * FROM users WHERE id = ‘1’ OR ‘1’=‘1’

这个 WHERE 条件将永远为真，导致查询出 users 表中的所有数据！这就是一次最简单的 基于字符串拼接的注入 。

更危险的攻击不止于查询。攻击者可以通过注入 UNION 语句来联合查询其他表，通过注入 ; 来执行多条语句（如 DROP TABLE users ），甚至利用数据库的存储过程进行系统命令调用。根据注入点参数类型，还可以分为 数字型注入 和 字符型注入 ，其闭合方式略有不同，但原理相通。

注意 ：很多新手会认为用了MyBatis等框架就高枕无忧了。这是一个巨大的误区！MyBatis中如果使用 ${} 进行参数拼接（如 ORDER BY ${column} ），同样存在SQL注入风险。 #{} 才是预编译占位符的正确用法。

2.2 XSS攻击：你的页面在替黑客运行脚本

XSS攻击的核心在于，攻击者提交的数据被浏览器当成了有效的脚本代码执行了。它主要分为三类：

1. 反射型XSS ：恶意脚本作为请求参数（如URL中的查询字符串）发送到服务器，服务器未经处理直接返回给浏览器执行。常见于搜索框、错误信息提示页。攻击者需要诱骗用户点击一个构造好的链接。
2. 存储型XSS ：恶意脚本被持久化保存到服务器数据库或文件中（如论坛帖子、用户评论），当其他用户浏览到该内容时自动执行。危害最大，因为受影响的是所有查看该内容的用户。
3. DOM型XSS ：前端的JavaScript代码在运行时，不安全地操作了DOM（例如使用 innerHTML 或 document.write ），将URL片段或用户输入直接当成了HTML或JS代码。漏洞发生在前端，不经过服务器。

一个存储型XSS的场景： 用户在一个博客评论区输入： <script>alert(‘你的Cookie是：’ + document.cookie);</script> 。 如果后端没有过滤，直接存入数据库。当其他用户访问这篇博客时，这段脚本就会在他们的浏览器中弹出包含其Cookie的警告框。如果脚本不是 alert ，而是将Cookie偷偷发送到攻击者的服务器，那么用户的会话就被劫持了。

理解这两种攻击的原理，你就会明白，防御的核心思路截然不同：防SQL注入，核心是让“数据”永远无法成为“代码”；防XSS，核心是对不可信的“数据”进行严格的“编码”或“过滤”，使其即使被当成代码也无法执行。

3. 防御体系构建：从编码习惯到架构选型

防御不是靠一个“银弹”函数，而是一套从代码编写到框架选型的组合拳。下面我结合多年实战，拆解每个环节的最佳实践。

3.1 SQL注入防御：让拼接成为历史

第一原则：永远使用参数化查询（预编译语句） 这是防御SQL注入最根本、最有效的方法，没有之一。它的原理是将SQL语句的 结构 与传入的 数据 完全分离。数据库引擎会先编译带占位符的SQL模板，确定执行计划，然后再将用户输入的数据作为纯粹的“参数值”传入。这样，无论参数值里包含什么SQL关键字或特殊字符，都只会被当作字符串或数字处理，而不会被解析为SQL语法。

Java JDBC标准做法：

// 错误做法：字符串拼接
// String sql = “SELECT * FROM t_user WHERE username = ‘“ + username + “’”;

// 正确做法：使用PreparedStatement
String sql = “SELECT * FROM t_user WHERE username = ? AND status = ?”;
try (PreparedStatement pstmt = connection.prepareStatement(sql)) {
    pstmt.setString(1, username); // 第一个问号替换为username的值
    pstmt.setInt(2, 1); // 第二个问号替换为数字1
    try (ResultSet rs = pstmt.executeQuery()) {
        // 处理结果集
    }
}

这里的关键是，即使用户名输入是 admin‘ -- ， setString 方法会将其作为一个完整的字符串值传递给查询，最终的查询等价于 SELECT * FROM t_user WHERE username = ‘admin‘ --’ AND status = 1 ，而 -- 在参数值里只是注释的一部分，不会生效。数据库寻找的是用户名为 admin‘ -- 的记录，自然找不到。

在ORM框架中的实践：

• JPA (Hibernate) : 使用 createQuery 配合命名参数或位置参数。

  // 命名参数
  TypedQuery<User> query = em.createQuery(
      “SELECT u FROM User u WHERE u.username = :name”, User.class);
  query.setParameter(“name”, username);
  
  // 或者使用Criteria API，这是类型安全且防注入的
  CriteriaBuilder cb = em.getCriteriaBuilder();
  CriteriaQuery<User> cq = cb.createQuery(User.class);
  Root<User> root = cq.from(User.class);
  cq.select(root).where(cb.equal(root.get(“username”), username));
  

• MyBatis : 坚决使用 #{} ，避免使用 ${} 。

  <!-- 安全 -->
  <select id=“selectUser” resultType=“User”>
      SELECT * FROM user WHERE username = #{username}
  </select>
  
  <!-- 危险！仅在动态排序等不得已场景使用，并必须严格白名单校验 -->
  <select id=“selectUserOrderBy” resultType=“User”>
      SELECT * FROM user
      ORDER BY ${orderByColumn} ${orderByDirection}
  </select>
  

  #{} 会被解析为预编译的 ? ，而 ${} 是直接的字符串替换。对于上面 ORDER BY 的例子，如果 orderByColumn 来自用户输入，必须在前端或后端Controller层将其限定在固定的几个列名白名单（如 “id” , “create_time” ）内。

第二道防线：最小权限原则与输入验证

• 数据库连接权限 ：应用连接数据库的账号，不应拥有 DROP 、 CREATE TABLE 、 FILE 权限等。只授予其完成业务所必需的 SELECT 、 INSERT 、 UPDATE 、 DELETE 权限。这样即使发生注入，破坏力也有限。
• 严格的输入验证 ：在数据进入业务逻辑前进行验证。例如，对于ID参数，验证其是否为整数；对于用户名，验证其长度和字符集（是否只包含字母数字）。使用Java Bean Validation ( javax.validation.constraints ) 是很好的实践。

  public class UserQueryDTO {
      @NotNull
      @Pattern(regexp = “^[a-zA-Z0-9_]{3,20}$”) // 用户名格式白名单
      private String username;
  
      @Min(1) // ID必须大于0
      private Long id;
      // getters and setters
  }
  

  但切记， 输入验证不能替代参数化查询 ！验证是为了保证数据符合业务规则，而参数化查询是为了保证SQL语法安全。两者是互补关系。

3.2 XSS防御：不相信任何来自用户的数据

防御XSS的黄金法则是： 对所有不可信的输入数据进行输出编码 。编码的位置，应该在数据 输出到不同上下文 时进行。

1. HTML内容编码（最常用） 当用户输入的数据需要作为HTML文本内容（如 <div> 标签内部、 <p> 标签内部）显示时，需要将特殊字符转换为HTML实体。

• < 转义为 <
• > 转义为 >
• & 转义为 &
• “ 转义为 "
• ‘ 转义为 ' (或 ' )

在Java中，可以使用以下工具：

• Apache Commons Text ： StringEscapeUtils.escapeHtml4(input)
• Spring Framework ： HtmlUtils.htmlEscape(input)
• OWASP Java Encoder ：这是OWASP官方推荐的项目，功能最全，上下文区分最细。

  import org.owasp.encoder.Encode;
  String safeOutput = Encode.forHtmlContent(userInput);
  

2. HTML属性编码 当用户输入需要放入HTML标签的属性值（如 <input value=“XXX”> ）时，除了HTML编码，还需要注意引号。应始终用双引号包裹属性值，并对内容中的引号进行编码。

String safeAttr = Encode.forHtmlAttribute(userInput);
// 输出类似：<input value=“${safeAttr}”>

3. JavaScript上下文编码 当需要将数据嵌入到 <script> 标签内时，情况更复杂。绝不能简单使用HTML编码！需要用反斜杠对特殊字符进行转义。

String safeForJS = Encode.forJavaScript(userInput);
// 假设userInput是 O‘Reilly
// 编码后为：O\x27Reilly

4. URL参数编码 当用户输入作为URL的一部分时（如跳转链接 href ），需要使用URL编码。

String safeForUrl = Encode.forUriComponent(userInput);

实战心得：框架的助力 现代Web框架大大简化了XSS防御：

• Thymeleaf / FreeMarker ：在模板中直接使用 th:text 或 ${...} 输出变量，默认就会进行HTML转义。如果确实需要输出原始HTML（比如富文本编辑器内容），必须使用 th:utext ，并确保该内容已经过安全的富文本过滤（如使用OWASP Java HTML Sanitizer）。
• JSP ：使用JSTL的 <c:out> 标签，其 escapeXml=“true” （默认）会进行转义。禁用此属性是危险的。
• 前端框架（Vue/React） ：它们的数据绑定（如 {{ }} 、 v-bind ）在默认情况下也会对纯文本进行转义。使用 v-html 或 dangerouslySetInnerHTML 时需要格外小心。

不可或缺的补充：HTTP安全头 在Web层，设置正确的HTTP响应头是重要的纵深防御措施：

• Content-Security-Policy (CSP) ：这是防御XSS的终极利器。它可以告诉浏览器只允许加载指定来源的脚本、样式、图片等。即使有恶意脚本被注入，如果其来源不在白名单内，浏览器也不会执行。

  // 在Spring Security中配置
  http.headers().contentSecurityPolicy(“script-src ‘self’ https://trusted.cdn.com;”);
  

  一个严格的CSP策略能极大限制XSS的影响。
• HttpOnly Cookie ：设置会话Cookie的 HttpOnly 属性，可以阻止JavaScript通过 document.cookie 访问此Cookie，缓解Cookie窃取型XSS的危害。

4. 全链路实战：一个用户查询与展示场景的完整安全实现

让我们通过一个完整的Spring Boot后端API示例，将上述所有防御措施串联起来。场景是：通过用户名查询用户信息，并返回给前端展示。

4.1 数据层（Repository） - 防御SQL注入

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // 方法1：使用Spring Data JPA的查询方法，安全
    Optional<User> findByUsername(String username);

    // 方法2：使用@Query注解配合参数化查询，安全
    @Query(“SELECT u FROM User u WHERE u.username = :uname”)
    Optional<User> findUserByUsername(@Param(“uname”) String username);

    // 方法3：使用原生查询，必须用参数化
    @Query(value = “SELECT * FROM users WHERE username = ?1”, nativeQuery = true)
    Optional<User> findNativeByUsername(String username);
}

这里无论哪种方式，框架底层都使用了预编译语句，是安全的。

4.2 服务层（Service） - 输入校验与业务逻辑

@Service
@Validated // 启用方法级校验
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public UserDTO getUserProfile(String username) {
        // 1. 输入校验（也可通过Controller层的@Validated实现）
        if (username == null || !username.matches(“^[a-zA-Z0-9_]{3,20}$”)) {
            throw new IllegalArgumentException(“Invalid username format”);
        }

        // 2. 安全查询
        User user = userRepository.findByUsername(username)
                .orElseThrow(() -> new ResourceNotFoundException(“User not found”));

        // 3. 数据脱敏（安全最佳实践）
        UserDTO dto = new UserDTO();
        dto.setId(user.getId());
        dto.setUsername(user.getUsername());
        dto.setDisplayName(user.getDisplayName());
        // 注意：不返回密码、邮箱等敏感信息
        return dto;
    }
}

4.3 控制层（Controller） - 接收请求与响应

@RestController
@RequestMapping(“/api/users”)
public class UserController {

    @Autowired
    private UserService userService;

    @GetMapping(“/profile”)
    public ResponseEntity<UserDTO> getProfile(
            @RequestParam @Pattern(regexp = “^[a-zA-Z0-9_]{3,20}$”) String username) {
        // @Validated 会触发参数校验，如果失败会抛出MethodArgumentNotValidException
        UserDTO userProfile = userService.getUserProfile(username);
        return ResponseEntity.ok(userProfile);
    }

    // 一个需要返回HTML片段（如用户签名）的接口示例
    @GetMapping(“/signature”)
    public ResponseEntity<Map<String, String>> getSignature(@RequestParam String username) {
        UserDTO user = userService.getUserProfile(username);
        String rawSignature = user.getSignature(); // 假设这是从数据库取出的用户签名，可能含HTML

        // 关键步骤：根据输出上下文进行编码
        Map<String, String> result = new HashMap<>();
        // 假设前端会将此字段放入<div>内作为HTML内容
        result.put(“signatureSafe”, Encode.forHtmlContent(rawSignature));
        // 假设前端会将此字段作为JavaScript变量
        result.put(“signatureForJs”, Encode.forJavaScript(rawSignature));

        return ResponseEntity.ok(result);
    }
}

4.4 全局配置（SecurityConfig） - 设置HTTP安全头

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .csrf().disable() // 根据API设计决定是否禁用CSRF
            .headers()
                .contentSecurityPolicy(“default-src ‘self’; script-src ‘self’ ‘unsafe-inline’ https://cdn.example.com; style-src ‘self’ ‘unsafe-inline’;”) // 根据实际情况配置
                .and()
                .httpStrictTransportSecurity().includeSubDomains(true).maxAgeInSeconds(31536000)
                .and()
                .frameOptions().deny() // 防止点击劫持
                .and()
                .xssProtection().block(true); // 启用浏览器XSS过滤

        // 其他授权规则...
    }
}

5. 进阶防御与运维层面考量

当基础防御做好后，我们需要从更高维度审视系统安全。

5.1 使用Web应用防火墙（WAF） WAF可以作为反向代理部署在应用前面，基于规则库识别和拦截常见的SQL注入、XSS等攻击特征。它是一种运行时防护，能有效抵御0day漏洞或未知的编码疏漏。但WAF不是万能的，规则可能被绕过，它应作为 纵深防御的一环 ，而非替代安全编码。

5.2 依赖组件安全扫描 你的项目依赖了大量的第三方库（Spring, MyBatis, Apache Commons等）。这些库本身可能存在已知漏洞。必须将安全扫描集成到CI/CD流程中。

• 工具 ：OWASP Dependency-Check、Snyk、GitHub Dependabot。
• 实践 ：在Maven或Gradle构建时自动扫描，对存在高危漏洞的依赖项，制定升级或缓解计划。

5.3 安全测试：将安全作为质量门禁

• 静态应用安全测试（SAST） ：使用SonarQube、Checkmarx等工具扫描源代码，寻找潜在的安全漏洞模式。
• 动态应用安全测试（DAST） ：使用OWASP ZAP、Burp Suite等工具对运行中的应用进行渗透测试，模拟黑客攻击。
• 自动化漏洞扫描 ：定期对线上环境进行授权扫描。
• 代码审计 ：建立同行代码审查制度，将安全作为审查的重点项之一。

5.4 日志与监控 记录所有安全相关事件，如登录失败、访问敏感接口、输入验证失败等。监控异常流量模式，例如某个接口突然出现大量带可疑参数的请求。使用ELK（Elasticsearch, Logstash, Kibana）或类似栈进行集中日志分析和告警。

6. 常见陷阱、疑难排查与实战心法

即使知道了最佳实践，在实际开发中还是会踩坑。下面是我总结的一些典型问题和解决方法。

6.1 MyBatis #{} 与 ${} 的混淆 这是最高频的错误。务必记住： #{} 是预编译占位符，安全； ${} 是字符串替换，危险 。只有在动态表名、列名（如 ORDER BY ）等无法使用预编译的场景，才考虑使用 ${} ，并且必须结合 白名单 校验。

<!-- 危险示例 -->
<select id=“dynamicQuery”>
    SELECT * FROM ${tableName} WHERE id = #{id}
</select>
<!-- 如果tableName来自用户输入，后果不堪设想 -->

<!-- 相对安全的做法（Java代码中校验） -->
<select id=“dynamicQuery”>
    SELECT * FROM ${tableName} WHERE id = #{id}
</select>

在调用该Mapper方法的Service层，必须确保 tableName 参数的值在一个预定义的白名单集合内（如 Set.of(“users”, “products”) ）。

6.2 富文本内容的XSS过滤 用户提交的富文本（如博客文章、商品详情）需要保留一些安全的HTML标签（如 <b> , <img> , <a> ），但不能包含脚本。这时不能使用简单的HTML编码（那会把所有标签都转义显示）。需要使用专业的HTML过滤库。

• OWASP Java HTML Sanitizer ：推荐使用。它允许你定义一套策略（Policy），指定允许的标签和属性。

  import org.owasp.html.PolicyFactory;
  import org.owasp.html.Sanitizers;
  PolicyFactory policy = Sanitizers.FORMATTING.and(Sanitizers.LINKS).and(Sanitizers.IMAGES);
  String safeHtml = policy.sanitize(userHtmlInput);
  

  这样， <script>alert(‘xss’)</script><p>Hello</p> 会被过滤为 <p>Hello</p> 。

6.3 JSON接口的XSS风险 很多人认为JSON接口返回数据，由前端渲染，所以后端不用管XSS。这是错误的！如果后端返回的JSON字符串中包含了未转义的HTML/JS代码，而前端又直接使用 innerHTML 或 eval （虽然不推荐）来处理，同样会触发XSS。

• 后端责任 ：确保返回给前端的数据是“干净”的。如果该数据最终会被用于HTML上下文，后端应进行HTML编码。或者，前后端约定，某些字段是“已消毒的HTML”（如富文本），前端可以安全使用 innerHTML ；其他字段是纯文本，前端必须使用 textContent 或经过编码的 innerText 。
• 前端责任 ：使用安全的API。用 textContent 替代 innerHTML ，用 JSON.parse 替代 eval 。使用现代框架（Vue/React）的数据绑定，它们默认提供了一层转义保护。

6.4 存储型XSS的二次触发 有时我们会对用户输入进行编码后存储，但在数据使用的不同环节可能出错。例如，用户输入被HTML编码后存入数据库（变成了 <script> ）。当另一个管理后台直接读取这个字段并展示时，如果管理后台没有输出编码，那么浏览器看到的就是 <script> 这个字符串，安全。但是，如果某个API接口错误地将这个已编码的字符串 又进行了一次解码 ，或者另一个系统直接读取了原始存储的数据，危险就又出现了。 最佳实践是：存储原始数据，在每次输出的具体上下文中进行编码。

6.5 调试与排查技巧

• 发现疑似SQL注入 ：查看应用日志中的SQL语句。如果看到完整的SQL语句中参数被直接拼接进去，那就是高危信号。使用Druid等连接池，其内置的SQL防火墙和日志功能可以帮助发现。
• 测试XSS防护 ：在输入框尝试提交一些测试向量，观察输出。
  • <script>alert(1)</script> – 测试基本脚本过滤。
  • <img src=“x” onerror=“alert(1)”> – 测试HTML属性事件过滤。
  • “><script>alert(1)</script> – 测试属性闭合。
  • javascript:alert(1) – 测试URL协议过滤。
• 使用安全工具 ：定期用OWASP ZAP对应用进行主动扫描，它能自动发现很多常见漏洞。

安全是一个持续的过程，不是一劳永逸的设置。它需要开发者在每一次代码提交、每一次功能设计时都保持警惕。从坚持使用 PreparedStatement 和输出编码开始，逐步建立起代码审计、依赖扫描、WAF防护的纵深防御体系，才能让你的Java后端应用在充满挑战的网络环境中真正地稳如磐石。