1. 项目概述：从“能跑就行”到“坚如磐石”的转变

干了这么多年Java开发，我见过太多项目在初期为了赶进度，把“安全性”三个字抛在脑后。大家最常挂在嘴边的一句话就是：“先把功能做出来，能跑就行，安全等上线前再加固。”结果往往是，这个“上线前”永远在明天，直到某天被安全扫描工具揪出一堆高危漏洞，或者更糟——被真实攻击打穿，才手忙脚乱地开始补窟窿。今天，我们就来深入聊聊Java Web开发中最常见、也最危险的两个“老朋友”：跨站脚本攻击（XSS）和SQL注入。这不仅仅是面试八股文里的两个名词，更是每一个后端开发者必须刻在骨子里的防御本能。无论你是刚入行的新手，还是在为下一次职级晋升准备“安全设计”案例的老兵，理解它们的原理、危害和防御手段，都是构建可靠系统的基石。我们将绕过教科书式的定义，直接从攻击者的视角看他们如何利用这些漏洞，然后以防御者的身份，用代码和配置筑起高墙。你会发现，很多有效的防御措施，并不需要高深莫测的技术，而是源于对细节的严谨和对“信任边界”的清晰认知。

2. 核心威胁剖析：XSS与SQL注入的攻击原理与场景

2.1 跨站脚本攻击（XSS）：当你的页面成了攻击者的扩音器

XSS的本质，是攻击者能够将恶意脚本代码“注入”到目标网站上，当其他用户浏览该页面时，这些脚本就会在用户的浏览器中执行。你可以把它想象成，有人在公共饮水机里下了药，所有来喝水的人都会中招。根据脚本的存储和执行位置，XSS主要分为三类，理解它们的区别对防御至关重要。

反射型XSS 是最常见的一种，通常通过URL参数传递。比如，一个搜索功能将用户输入的关键词直接回显在页面上。如果攻击者构造一个这样的URL并发给受害者： http://vulnerable-site.com/search?keyword=<script>alert('XSS')</script> ，而后端未做任何处理就直接将 keyword 的值输出到HTML中，那么受害者打开这个链接时，就会弹出一个警告框。在实际攻击中， alert 会被替换成窃取用户Cookie（尤其是Session ID）的脚本，攻击者拿到Cookie后就能冒充用户登录。这种攻击依赖用户点击恶意链接，常见于钓鱼邮件、论坛帖子中的短链接。

存储型XSS 的危害性更大，因为恶意脚本被“存储”在了服务器上，比如数据库、评论内容、用户昵称字段。任何一个访问到该内容的用户都会中招。一个经典的场景是论坛的评论系统。攻击者在评论框中输入一段包含恶意脚本的评论，提交后，这段评论被存入数据库。此后，所有浏览这个帖子的用户，其浏览器都会执行这段脚本，可能导致大规模的用户Cookie被盗、页面被篡改（如增加钓鱼表单）、甚至利用浏览器漏洞下载木马。因为它的持久性，存储型XSS常被用来制作“网页挂马”。

DOM型XSS 比较特殊，它的恶意代码注入和解析执行完全发生在客户端的浏览器中，不经过服务器。攻击载荷通常隐藏在URL的片段标识（ # 后面）或通过前端JavaScript操作DOM（如 document.write 、 innerHTML 、 location.hash ）来触发。例如，一个页面使用 eval(location.hash.substring(1)) 这样的危险代码来处理锚点，那么攻击者构造 http://site.com/page#alert('xss') 的链接，就会触发攻击。由于不经过服务器，传统的服务端输入过滤可能对它无效，防御重心需要转移到前端的安全编码上。

注意 ：很多开发者认为用了现代前端框架（如React, Vue）就高枕无忧了，因为它们默认会对渲染内容进行转义。这有一定道理，但绝非绝对安全。当你使用 dangerouslySetInnerHTML （React）或 v-html （Vue）指令时，就相当于主动关闭了这道安全门，风险依然存在。

2.2 SQL注入：让数据库对你“敞开心扉”

如果说XSS是针对浏览器和用户的攻击，那么SQL注入就是直指应用核心——数据库的攻击。它的原理是，攻击者通过在应用程序的输入参数中插入恶意的SQL代码，使得后端程序在拼接SQL语句时，改变了原有的查询逻辑。

想象一下，你有一个用户登录的SQL语句是这样拼接的：

String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

如果用户在用户名输入框里输入 admin'-- （注意最后的两个减号是SQL中的单行注释符），那么拼接后的SQL就变成了：

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

-- 后面的内容被注释掉了，这意味着攻击者无需知道密码，就能以管理员身份登录。这是最经典的“永真式”注入。

更危险的攻击远不止于此。通过联合查询（UNION），攻击者可以窃取其他表的数据；通过堆叠查询（Stacked Queries，依赖数据库驱动支持），可以执行任意SQL语句，进行增删改查，甚至调用存储过程；通过布尔盲注或时间盲注，即使在页面没有明确错误回显的情况下，也能像“猜谜”一样逐位获取数据。在渗透测试靶场如DVWA、Pikachu或CTF题目中，SQL注入往往是突破的第一道关卡，因为它直接关联着最宝贵的数据资产。

一个容易被忽略的误区 ：很多人觉得用了ORM框架（如MyBatis, Hibernate）就免疫SQL注入了。实际上，ORM框架只是降低了手写拼接SQL的概率，但如果你在MyBatis中这样写：

<select id="findUser" parameterType="String" resultType="User">
    SELECT * FROM users WHERE username = '${username}'
</select>

使用了 ${} 而不是 #{} ，它依然会进行直接的字符串替换，注入漏洞依旧存在。Hibernate的HQL如果使用字符串拼接，同样存在类似问题。

3. 防御体系构建：从编码到架构的纵深防御

知道了攻击怎么来，我们就要构建一套立体的防御体系。安全没有银弹，单一措施很容易被绕过，必须采用纵深防御（Defense in Depth）的策略。

3.1 对抗XSS：输入过滤、输出编码与内容安全策略

防御XSS的核心思想很简单： 永远不要信任用户输入，对所有输出到页面的动态内容进行编码或转义 。但这简单的思想，需要落实到具体的技术点上。

1. 服务端输入验证与过滤 这是第一道防线，目的是确保进入系统的数据符合预期的格式和类型。但这 不能 作为唯一的防线，因为“过滤”的规则可能被绕过。

• 白名单优于黑名单 ：定义什么是允许的（如只允许字母、数字和特定符号），比定义什么是不允许的（如尝试过滤 <script> ）要安全得多。黑名单总会遗漏。
• 使用成熟的工具库 ：不要自己写复杂的正则表达式去过滤HTML。推荐使用OWASP Java Encoder项目提供的 ESAPI.encoder().encodeForHTML() ，或者Apache Commons Text中的 StringEscapeUtils.escapeHtml4() 。对于更复杂的场景，可以考虑Jsoup库，它不仅能清理HTML，还能提供一个安全的HTML文档对象模型。

2. 输出编码（最关键的一步） 这是防御XSS最有效、最根本的手段。编码的意义在于，将数据中的特殊字符（如 < , > , & , " , ' ）转换成它们的HTML实体（如 < , > , & , " , ' ），这样浏览器就会将其解释为普通文本，而不是可执行的代码。

• 上下文决定编码方式 ：编码不是一成不变的，取决于你的数据将要被放入哪个上下文。
  • HTML Body上下文 ：使用HTML实体编码。 <script>alert(1)</script> 会变成 <script>alert(1)</script> 。
  • HTML Attribute上下文 ：除了HTML实体编码，还要注意用引号包裹属性值。 onclick="alert(' 需要被正确处理。
  • JavaScript上下文 ：需要将数据放入JS字符串时，要进行JavaScript Unicode转义。 userInput 可能被转义为 \u0075\u0073... 。
  • URL上下文 ：在拼接URL参数时，必须进行URL编码（百分号编码）。
• 模板引擎的自动转义 ：现代模板引擎（如Thymeleaf, FreeMarker）默认开启了HTML转义。 请务必不要轻易关闭这个功能 。在Thymeleaf中，使用 th:text 属性会自动转义，而 th:utext 则不会，使用后者时需要万分小心。

3. 内容安全策略（CSP） 这是一个由浏览器提供的、强大的深度防御安全层。它通过HTTP响应头 Content-Security-Policy 来告诉浏览器，哪些外部资源（脚本、样式、图片、字体等）可以被加载和执行。即使攻击者成功注入了脚本，如果该脚本的来源不在CSP允许的白名单内，浏览器也不会执行它。 一个基础的CSP头可以这样设置（在Spring Security或过滤器中）：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline';

这个策略表示：默认只允许加载同源资源；脚本只允许同源和指定的CDN；样式允许同源和内联样式（ unsafe-inline 是一个风险点，应尽量避免）。启用CSP能极大缓解XSS的影响，是Web应用安全的“标配”。

4. 设置安全的Cookie属性 对于Session Cookie，务必设置 HttpOnly 和 Secure 属性。

• HttpOnly ：阻止JavaScript通过 document.cookie API访问该Cookie，这样即使发生XSS，攻击者也无法直接窃取Session ID。
• Secure ：要求浏览器只在HTTPS连接中发送此Cookie，防止在明文传输中被窃听。 在Servlet中可以通过 setHttpOnly(true) 和 setSecure(true) 来设置。

3.2 根治SQL注入：参数化查询与最小权限原则

防御SQL注入的方法论非常明确： 使用参数化查询（预编译语句），永远不要拼接SQL字符串 。

1. 使用PreparedStatement 这是JDBC层面防御SQL注入的基石。它的原理是将SQL语句的“结构”与“数据”分开发送数据库。数据库先对SQL结构（带占位符 ? ）进行编译，确定执行计划，然后再将用户输入的数据作为“参数”传入。此时，即使用户输入中包含SQL元字符，也只会被当作普通字符串数据来处理，无法改变SQL语句的原有结构。

// 正确做法：使用PreparedStatement
String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, username); // 参数1被安全地设置
pstmt.setString(2, password); // 参数2被安全地设置
ResultSet rs = pstmt.executeQuery();

// 错误做法：字符串拼接（绝对禁止！）
// String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
// Statement stmt = connection.createStatement();
// ResultSet rs = stmt.executeQuery(sql);

2. 在ORM框架中正确使用参数绑定

• MyBatis ： 坚决使用 #{} 语法 。 #{} 会被解析为JDBC的 PreparedStatement 参数占位符 ? 。而 ${} 是字符串替换，存在注入风险，除非在极少数需要动态指定列名或表名的场景（且该值必须来自可信白名单），否则不应使用。
• JPA / Hibernate ：使用命名参数或位置参数。

  // 使用命名参数（推荐）
  Query query = em.createQuery("SELECT u FROM User u WHERE u.username = :uname");
  query.setParameter("uname", username);
  
  // 或使用位置参数
  Query query = em.createQuery("SELECT u FROM User u WHERE u.username = ?1");
  query.setParameter(1, username);
  

  同样，避免使用字符串拼接来构造JPQL/HQL。

3. 实施最小权限原则 为应用程序连接数据库的账户分配 最小必要权限 。这个账户通常只需要对特定的业务表有 SELECT , INSERT , UPDATE , DELETE 权限，绝对不应该拥有 DROP , CREATE , ALTER 等数据库管理权限，更不应是 sa 或 root 账号。这样即使发生注入，攻击者能造成的破坏也被限制在有限范围内。

4. 输入验证与白名单 对于某些无法使用参数化查询的极端情况（如动态排序字段 ORDER BY 子句），必须采用严格的白名单验证。例如，如果前端传递一个 sortBy 参数，后端应该检查其值是否在预定义的允许列表内（如 ["id", "name", "createTime"] ），而不是直接拼接到SQL中。

4. 实战演练：在Spring Boot项目中落地安全实践

理论说再多，不如一行代码。我们以一个典型的Spring Boot Web应用为例，看看如何将上述防御措施整合起来。

4.1 依赖配置与基础防护

首先，在 pom.xml 中引入安全相关的依赖。OWASP Java Encoder和Spring Security是核心。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
    <groupId>org.owasp.encoder</groupId>
    <artifactId>encoder</artifactId>
    <version>1.2.3</version> <!-- 使用最新版本 -->
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-text</artifactId>
    <version>1.10.0</version>
</dependency>

4.2 配置HTTP安全头与CSP

通过配置Spring Security，我们可以轻松地为所有响应添加关键的安全头。

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.header.writers.StaticHeadersWriter;

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .headers(headers -> headers
                // 添加CSP头，禁止内联脚本，只允许同源资源
                .contentSecurityPolicy(csp -> csp
                    .policyDirectives("default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:;")
                )
                // 防止浏览器进行MIME类型嗅探，降低某些XSS变种风险
                .contentTypeOptions(withDefaults())
                // 强制浏览器使用HTTPS（如果部署了HTTPS）
                .httpStrictTransportSecurity(hsts -> hsts
                    .includeSubDomains(true)
                    .preload(true)
                    .maxAgeInSeconds(31536000) // 1年
                )
                // 防止页面在frame中加载，对抗点击劫持
                .frameOptions(frame -> frame.sameOrigin())
            )
            // 配置Session Cookie为HttpOnly和Secure
            .sessionManagement(session -> session
                .sessionFixation().migrateSession()
            );
        // 其他授权规则...
        return http.build();
    }
}

在 application.yml 中，也可以全局配置Servlet容器的Session Cookie安全属性：

server:
  servlet:
    session:
      cookie:
        http-only: true
        secure: true # 生产环境HTTPS下启用

4.3 数据持久层安全编码

使用Spring Data JPA（Hibernate）:

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // 方法名查询或@Query注解使用参数绑定是安全的
    User findByUsername(String username);

    @Query("SELECT u FROM User u WHERE u.email = :email")
    User findUserByEmail(@Param("email") String email);
}

使用MyBatis: 在Mapper XML文件中，务必使用 #{} 。

<!-- UserMapper.xml -->
<select id="selectUserByLogin" resultType="User">
    SELECT id, username, email FROM users
    WHERE username = #{username} AND password = #{password}
    <!-- #{username} 会被安全地处理为参数 -->
</select>

直接使用JdbcTemplate:

@Repository
public class UserDao {
    @Autowired
    private JdbcTemplate jdbcTemplate;

    public User findUser(String username) {
        String sql = "SELECT * FROM users WHERE username = ?";
        // 使用参数化查询
        return jdbcTemplate.queryForObject(sql, new Object[]{username}, new UserRowMapper());
    }
}

4.4 视图层输出编码

在Thymeleaf模板中，默认的 th:text 是安全的。

<!-- 安全：会自动进行HTML转义 -->
<p th:text="${userInput}"></p>

<!-- 危险：需要确保userInput绝对可信 -->
<p th:utext="${trustedHtml}"></p>

在Controller或Service层，如果需要对特定字符串进行编码，可以使用OWASP Encoder：

import org.owasp.encoder.Encode;
// ...
model.addAttribute("safeOutput", Encode.forHtml(userProvidedContent));

5. 进阶防护与安全开发流程

5.1 使用Web应用防火墙（WAF）

对于已上线或遗留系统，在代码层面全面修复所有漏洞可能成本高昂。部署一个WAF（如ModSecurity）可以作为一道有效的缓冲防线。WAF通过预定义的规则集（如OWASP Core Rule Set）来识别和阻断常见的攻击模式（XSS、SQL注入、路径遍历等）。但要注意，WAF是“虚拟补丁”，不能替代安全的代码，复杂的攻击或规则未覆盖的0day漏洞可能绕过WAF。

5.2 依赖组件安全扫描

现代Java项目大量依赖第三方库（Maven/Gradle）。这些库本身也可能存在漏洞。必须将安全扫描纳入CI/CD流程。可以使用OWASP Dependency-Check或Sonatype Nexus IQ等工具，在构建时自动检查项目依赖的已知漏洞（CVE），并给出升级建议。

5.3 将安全融入开发生命周期（DevSecOps）

安全不是测试阶段或上线前的“附加动作”，而应贯穿整个软件开发生命周期（SDLC）。

• 需求与设计阶段 ：进行威胁建模，识别潜在的安全威胁和攻击面。
• 编码阶段 ：遵循安全编码规范，使用安全的API，进行结对编程或代码审查时重点关注安全点。
• 构建阶段 ：集成SAST（静态应用安全测试）工具，如SonarQube（配合安全插件）、Checkmarx，对源代码进行漏洞扫描。
• 测试阶段 ：进行DAST（动态应用安全测试），使用ZAP、Burp Suite等工具对运行中的应用进行自动化渗透测试。同时进行手动安全测试。
• 部署与运维阶段 ：配置安全的生产环境，定期进行漏洞扫描和渗透测试。

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

在实际开发和维护中，你可能会遇到以下典型问题：

问题1：明明用了PreparedStatement，日志里还是看到了注入语句？ 这通常是日志记录方式的问题。有些日志框架或中间件（如Druid连接池的SQL日志）记录的是拼接后的完整SQL语句，用于调试。但这并不意味着注入成功了。数据库驱动在发送时，依然是分“结构”和“参数”两部分的。你可以通过抓取网络包或使用数据库自身的日志来确认。

问题2：Thymeleaf模板中，如何安全地输出JSON数据供前端JS使用？ 这是一个高频场景。错误做法是： <script>var data = [[${jsonString}]];</script> ，如果 jsonString 包含 </script> 就会破坏结构。正确做法是：

1. 在Controller中，将对象直接放入Model，Thymeleaf可以将其序列化为JSON。
2. 或者，使用 th:inline="javascript" 并确保内容被正确转义，但更推荐使用 <script th:inline="javascript">/*<![CDATA[*/ var data = [[${data}]]; /*]]>*/</script> ，其中 [[${data}]] 会输出JSON字符串并被转义。
3. 最佳实践 ：通过单独的API接口（如 /api/data ）以 application/json 格式返回数据，前端用AJAX获取。彻底避免在HTML中嵌入复杂数据。

问题3：MyBatis中 ${} 到底什么时候能用？ 极其有限的场景，且必须配合严格的白名单。例如动态表名（分表场景），但表名必须来自程序内部枚举或配置，绝不能来自用户输入。更安全的做法是使用MyBatis的 <choose> 或 <when> 标签进行逻辑判断，或者通过数据库中间件解决分表问题。

问题4：验证码能防止SQL注入和XSS吗？ 不能。 验证码主要用于防止自动化攻击（如撞库、批量注册、暴力破解）。它无法防止手动构造的、单次的注入或XSS攻击载荷。防御这些漏洞的根本在于服务端对输入的处理和输出的编码。

问题5：HTTPS能防止这些攻击吗？ 不能。 HTTPS（SSL/TLS）解决的是通信链路上的“窃听”和“篡改”问题，即保证数据从客户端到服务器的传输过程是加密且完整的。XSS和SQL注入是发生在应用逻辑层面的漏洞，攻击载荷是通过加密通道“正大光明”地送进来的。HTTPS是必需品，但它不是应用安全问题的万能药。

踩过这么多坑，我的最深体会是：安全是一种“非功能需求”，但它必须像功能需求一样被明确设计、实现和测试。建立一个团队内的安全编码规范，在Code Review中加入安全检查点，定期进行安全培训，让每个开发者都具备基本的安全意识，远比在出事后再救火要有效得多。从今天开始，在写下每一行处理用户输入的代码时，都多问自己一句：“如果这里输入的是恶意内容，会发生什么？” 这个习惯，可能就是你的系统免于灾难的关键。