1. 为什么Spring Boot应用需要双重防护？
在Web应用开发中，XSS和SQL注入是两种最常见也最危险的安全威胁。去年OWASP发布的十大Web应用安全风险中，注入类漏洞（包括SQL注入）高居榜首，而XSS漏洞也长期位列前三。这两种攻击手段虽然原理不同，但都能造成严重后果——轻则数据泄露，重则系统沦陷。
我去年参与审计的一个电商项目中，就曾发现一个典型的组合漏洞：通过商品评价字段插入XSS脚本获取管理员Cookie后，攻击者利用后台系统的SQL注入漏洞直接拖走了整个用户数据库。这种"XSS探路+SQL注入收割"的攻击模式，正在成为黑产的标配手段。
Spring Boot作为当前最流行的Java Web框架，其自动配置特性在带来便利的同时，也容易让开发者忽略底层安全机制。默认情况下，Spring Boot并不提供完整的XSS和SQL注入防护，需要开发者主动配置。下面我们就深入这两种攻击的原理及防护方案。
2. XSS攻击全解析与防护实践
2.1 XSS攻击的三种形态对比
根据攻击载荷的存储位置和执行方式，XSS通常分为三类：
| 类型 | 存储位置 | 触发方式 | 危害周期 | 典型案例 |
|---|---|---|---|---|
| 存储型 | 服务器数据库 | 用户访问正常页面 | 长期持续 | 论坛恶意评论 |
| 反射型 | URL参数 | 用户点击恶意链接 | 一次性 | 钓鱼邮件中的伪装链接 |
| DOM型 | 前端代码 | 本地JS执行 | 客户端环境 | 恶意修改页面DOM结构 |
去年某社交平台爆出的XSS漏洞就属于存储型，攻击者在个人简介中植入脚本，导致每个访问其主页的用户都会执行恶意代码。
2.2 Spring Boot中的XSS防护方案
方案一：HTML转义过滤器（推荐）
创建XSS过滤器是最彻底的解决方案。以下是基于HttpServletRequestWrapper的实现：
public class XssHttpServletRequestWrapper extends HttpServletRequestWrapper { private static final HTMLPolicyBuilder POLICY_BUILDER = new HTMLPolicyBuilder(); public XssHttpServletRequestWrapper(HttpServletRequest request) { super(request); } @Override public String getParameter(String name) { return escapeHtml(super.getParameter(name)); } @Override public String[] getParameterValues(String name) { String[] values = super.getParameterValues(name); if(values == null) return null; return Arrays.stream(values).map(this::escapeHtml).toArray(String[]::new); } private String escapeHtml(String raw) { if(StringUtils.isEmpty(raw)) return raw; return POLICY_BUILDER.sanitize(raw); } }注册过滤器时需要注意顺序问题，必须放在Spring Security过滤器链之前：
@Bean public FilterRegistrationBean<XssFilter> xssFilter() { FilterRegistrationBean<XssFilter> registration = new FilterRegistrationBean<>(); registration.setFilter(new XssFilter()); registration.addUrlPatterns("/*"); registration.setOrder(Ordered.HIGHEST_PRECEDENCE); // 最高优先级 return registration; }方案二：模板引擎自动转义
Thymeleaf和FreeMarker等模板引擎默认开启HTML转义：
<!-- Thymeleaf示例 --> <div th:text="${userInput}"></div> <!-- 会自动转义特殊字符 -->但要注意，使用th:utext或Freemarker的?no_esc会禁用转义，这相当于在代码中埋下XSS隐患。
方案三：Response头设置
增加安全相关的HTTP头作为防御纵深：
@Configuration public class SecurityConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new HandlerInterceptorAdapter() { @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) { response.setHeader("X-XSS-Protection", "1; mode=block"); response.setHeader("Content-Security-Policy", "default-src 'self'"); } }); } }重要提示：现代浏览器已逐步移除X-XSS-Protection支持，CSP（Content Security Policy）才是未来方向。但CSP配置复杂，建议先从过滤器方案入手。
3. SQL注入攻防实战
3.1 SQL注入的典型攻击模式
通过分析阿里云云盾拦截的攻击日志，常见的SQL注入手法包括：
布尔盲注：通过真假条件判断数据
' AND 1=CONVERT(int, (SELECT table_name FROM information_schema.tables))--时间盲注：利用延时函数推断信息
'; IF(SUBSTRING(@@version,1,1)='5', SLEEP(5), 0)--报错注入：触发数据库错误泄露信息
' AND GTID_SUBSET(@@version,0)--堆叠查询：执行多条语句获取控制权
'; DROP TABLE users;--
3.2 MyBatis防护方案对比
| 方案 | 原理 | 性能影响 | 防护效果 | 适用场景 |
|---|---|---|---|---|
| #{}预处理 | 参数化查询 | 无 | ★★★★★ | 常规查询 |
| ${}白名单过滤 | 关键字段校验 | 轻微 | ★★★☆☆ | 动态表名/列名 |
| XML特殊符号转义 | 转义<,>等 | 中等 | ★★☆☆☆ | 旧系统兼容 |
| 存储过程 | 隔离SQL逻辑 | 视情况 | ★★★★☆ | 复杂业务逻辑 |
最佳实践：预处理语句+白名单
@Select("SELECT * FROM #{table} WHERE id = #{id}") User getUser(@Param("table") String table, @Param("id") Long id); // 表名白名单校验 public String checkTableName(String input) { Set<String> allowedTables = Set.of("users", "products"); if(!allowedTables.contains(input.toLowerCase())) { throw new IllegalArgumentException("Invalid table name"); } return input; }3.3 JPA/Hibernate的防护机制
使用JPA时要注意几个特殊场景：
Native SQL查询必须使用参数绑定：
// 错误示范 String sql = "SELECT * FROM users WHERE name = '" + name + "'"; // 正确做法 String sql = "SELECT * FROM users WHERE name = ?1"; Query query = em.createNativeQuery(sql).setParameter(1, name);排序字段需要特殊处理：
// 不安全 String jql = "FROM User ORDER BY " + sortField; // 安全做法 CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<User> cq = cb.createQuery(User.class); Root<User> root = cq.from(User.class); cq.orderBy(cb.asc(root.get(sortField))); // 自动校验字段名
4. 综合防御体系构建
4.1 防御层级设计
完整的防护应该包含以下层次：
输入层：XSS过滤器+参数校验
@NotBlank @Size(max=100) private String username;处理层：ORM安全配置+最小权限原则
spring: datasource: hikari: connection-init-sql: "SET SESSION sql_mode='STRICT_TRANS_TABLES'"输出层：响应头+CSP策略
response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self' 'unsafe-inline'");监控层：SQL防火墙+请求日志分析
<!-- logback配置 --> <logger name="org.hibernate.SQL" level="DEBUG"/> <logger name="org.hibernate.type.descriptor.sql.BasicBinder" level="TRACE"/>
4.2 实战中的典型误区和修正
误区一：依赖WAF就万事大吉
- 问题：WAF规则可能被绕过，且无法防护应用层逻辑漏洞
- 修正：应在代码层面实现安全控制，WAF作为补充
误区二：前端校验代替后端防护
- 问题：攻击者可直接构造请求绕过前端
- 修正：所有校验必须在后端重复执行
误区三：过度信任框架默认配置
- 问题：Spring Boot的security默认配置可能不够严格
- 修正：主动配置安全策略，例如：
@Configuration @EnableWebSecurity public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() // 谨慎！仅限API服务 .headers() .xssProtection() .and() .contentSecurityPolicy("script-src 'self'"); } }
5. 安全测试验证方案
5.1 自动化测试工具链
OWASP ZAP：自动化扫描XSS和SQL注入
docker run -v $(pwd):/zap/wrk -t owasp/zap2docker zap-baseline.py \ -t https://your-applicationSQLMap测试MyBatis接口：
sqlmap -u "http://api.example.com/users?id=1" --risk=3 --level=5JUnit集成测试：
@Test void testXssProtection() { mockMvc.perform(post("/submit") .param("content", "<script>alert(1)</script>")) .andExpect(content().string(not(containsString("<script>")))); }
5.2 人工测试用例集
| 测试类型 | 测试输入 | 预期结果 |
|---|---|---|
| XSS | <img src=x onerror=alert(1)> | 转义为文本显示 |
| SQL注入 | ' OR '1'='1 | 返回空结果或错误 |
| 边界测试 | 5000个字符的输入 | 被合理截断或拒绝 |
| 编码绕过 | %3Cscript%3Ealert(1)%3C/script%3E | 仍被识别并过滤 |
在实际项目中，我建议建立安全测试checklist，将上述测试用例纳入持续集成流程。特别是对于关键业务接口，应该同时实施静态代码扫描（如SonarQube）和动态渗透测试，形成多层次的质量门禁。
