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攻击的核心在于攻击者提交的数据被浏览器当成了有效的脚本代码执行了。它主要分为三类反射型XSS恶意脚本作为请求参数如URL中的查询字符串发送到服务器服务器未经处理直接返回给浏览器执行。常见于搜索框、错误信息提示页。攻击者需要诱骗用户点击一个构造好的链接。存储型XSS恶意脚本被持久化保存到服务器数据库或文件中如论坛帖子、用户评论当其他用户浏览到该内容时自动执行。危害最大因为受影响的是所有查看该内容的用户。DOM型XSS前端的JavaScript代码在运行时不安全地操作了DOM例如使用innerHTML或document.write将URL片段或用户输入直接当成了HTML或JS代码。漏洞发生在前端不经过服务器。一个存储型XSS的场景用户在一个博客评论区输入scriptalert(‘你的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配合命名参数或位置参数。// 命名参数 TypedQueryUser query em.createQuery( “SELECT u FROM User u WHERE u.username :name”, User.class); query.setParameter(“name”, username); // 或者使用Criteria API这是类型安全且防注入的 CriteriaBuilder cb em.getCriteriaBuilder(); CriteriaQueryUser cq cb.createQuery(User.class); RootUser 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实体。转义为lt;转义为gt;转义为amp;“转义为quot;‘转义为#x27;(或apos;)在Java中可以使用以下工具Apache Commons TextStringEscapeUtils.escapeHtml4(input)Spring FrameworkHtmlUtils.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\x27Reilly4. 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 JpaRepositoryUser, Long { // 方法1使用Spring Data JPA的查询方法安全 OptionalUser findByUsername(String username); // 方法2使用Query注解配合参数化查询安全 Query(“SELECT u FROM User u WHERE u.username :uname”) OptionalUser findUserByUsername(Param(“uname”) String username); // 方法3使用原生查询必须用参数化 Query(value “SELECT * FROM users WHERE username ?1”, nativeQuery true) OptionalUser 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 ResponseEntityUserDTO 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 ResponseEntityMapString, String getSignature(RequestParam String username) { UserDTO user userService.getUserProfile(username); String rawSignature user.getSignature(); // 假设这是从数据库取出的用户签名可能含HTML // 关键步骤根据输出上下文进行编码 MapString, 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应用防火墙WAFWAF可以作为反向代理部署在应用前面基于规则库识别和拦截常见的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 日志与监控记录所有安全相关事件如登录失败、访问敏感接口、输入验证失败等。监控异常流量模式例如某个接口突然出现大量带可疑参数的请求。使用ELKElasticsearch, 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);这样scriptalert(‘xss’)/scriptpHello/p会被过滤为pHello/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编码后存入数据库变成了lt;scriptgt;。当另一个管理后台直接读取这个字段并展示时如果管理后台没有输出编码那么浏览器看到的就是lt;scriptgt;这个字符串安全。但是如果某个API接口错误地将这个已编码的字符串又进行了一次解码或者另一个系统直接读取了原始存储的数据危险就又出现了。最佳实践是存储原始数据在每次输出的具体上下文中进行编码。6.5 调试与排查技巧发现疑似SQL注入查看应用日志中的SQL语句。如果看到完整的SQL语句中参数被直接拼接进去那就是高危信号。使用Druid等连接池其内置的SQL防火墙和日志功能可以帮助发现。测试XSS防护在输入框尝试提交一些测试向量观察输出。scriptalert(1)/script– 测试基本脚本过滤。img src“x” onerror“alert(1)”– 测试HTML属性事件过滤。“scriptalert(1)/script– 测试属性闭合。javascript:alert(1)– 测试URL协议过滤。使用安全工具定期用OWASP ZAP对应用进行主动扫描它能自动发现很多常见漏洞。安全是一个持续的过程不是一劳永逸的设置。它需要开发者在每一次代码提交、每一次功能设计时都保持警惕。从坚持使用PreparedStatement和输出编码开始逐步建立起代码审计、依赖扫描、WAF防护的纵深防御体系才能让你的Java后端应用在充满挑战的网络环境中真正地稳如磐石。
Java后端安全实战：SQL注入与XSS攻击的防御体系构建
发布时间：2026/7/4 16:52:58
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攻击的核心在于攻击者提交的数据被浏览器当成了有效的脚本代码执行了。它主要分为三类反射型XSS恶意脚本作为请求参数如URL中的查询字符串发送到服务器服务器未经处理直接返回给浏览器执行。常见于搜索框、错误信息提示页。攻击者需要诱骗用户点击一个构造好的链接。存储型XSS恶意脚本被持久化保存到服务器数据库或文件中如论坛帖子、用户评论当其他用户浏览到该内容时自动执行。危害最大因为受影响的是所有查看该内容的用户。DOM型XSS前端的JavaScript代码在运行时不安全地操作了DOM例如使用innerHTML或document.write将URL片段或用户输入直接当成了HTML或JS代码。漏洞发生在前端不经过服务器。一个存储型XSS的场景用户在一个博客评论区输入scriptalert(‘你的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配合命名参数或位置参数。// 命名参数 TypedQueryUser query em.createQuery( “SELECT u FROM User u WHERE u.username :name”, User.class); query.setParameter(“name”, username); // 或者使用Criteria API这是类型安全且防注入的 CriteriaBuilder cb em.getCriteriaBuilder(); CriteriaQueryUser cq cb.createQuery(User.class); RootUser 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实体。转义为lt;转义为gt;转义为amp;“转义为quot;‘转义为#x27;(或apos;)在Java中可以使用以下工具Apache Commons TextStringEscapeUtils.escapeHtml4(input)Spring FrameworkHtmlUtils.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\x27Reilly4. 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 JpaRepositoryUser, Long { // 方法1使用Spring Data JPA的查询方法安全 OptionalUser findByUsername(String username); // 方法2使用Query注解配合参数化查询安全 Query(“SELECT u FROM User u WHERE u.username :uname”) OptionalUser findUserByUsername(Param(“uname”) String username); // 方法3使用原生查询必须用参数化 Query(value “SELECT * FROM users WHERE username ?1”, nativeQuery true) OptionalUser 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 ResponseEntityUserDTO 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 ResponseEntityMapString, String getSignature(RequestParam String username) { UserDTO user userService.getUserProfile(username); String rawSignature user.getSignature(); // 假设这是从数据库取出的用户签名可能含HTML // 关键步骤根据输出上下文进行编码 MapString, 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应用防火墙WAFWAF可以作为反向代理部署在应用前面基于规则库识别和拦截常见的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 日志与监控记录所有安全相关事件如登录失败、访问敏感接口、输入验证失败等。监控异常流量模式例如某个接口突然出现大量带可疑参数的请求。使用ELKElasticsearch, 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);这样scriptalert(‘xss’)/scriptpHello/p会被过滤为pHello/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编码后存入数据库变成了lt;scriptgt;。当另一个管理后台直接读取这个字段并展示时如果管理后台没有输出编码那么浏览器看到的就是lt;scriptgt;这个字符串安全。但是如果某个API接口错误地将这个已编码的字符串又进行了一次解码或者另一个系统直接读取了原始存储的数据危险就又出现了。最佳实践是存储原始数据在每次输出的具体上下文中进行编码。6.5 调试与排查技巧发现疑似SQL注入查看应用日志中的SQL语句。如果看到完整的SQL语句中参数被直接拼接进去那就是高危信号。使用Druid等连接池其内置的SQL防火墙和日志功能可以帮助发现。测试XSS防护在输入框尝试提交一些测试向量观察输出。scriptalert(1)/script– 测试基本脚本过滤。img src“x” onerror“alert(1)”– 测试HTML属性事件过滤。“scriptalert(1)/script– 测试属性闭合。javascript:alert(1)– 测试URL协议过滤。使用安全工具定期用OWASP ZAP对应用进行主动扫描它能自动发现很多常见漏洞。安全是一个持续的过程不是一劳永逸的设置。它需要开发者在每一次代码提交、每一次功能设计时都保持警惕。从坚持使用PreparedStatement和输出编码开始逐步建立起代码审计、依赖扫描、WAF防护的纵深防御体系才能让你的Java后端应用在充满挑战的网络环境中真正地稳如磐石。
![华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-字符串变换最小次数[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
![华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率](http://pic.xiahunao.cn/yaotu/华为OD机试2025C卷-内存资源分配[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率)
