1. 项目概述为什么Java开发者必须亲手搞定SQL注入与XSS干了这么多年Java后端我见过太多因为SQL注入和XSS攻击导致的“惨案”。有次凌晨两点被电话叫醒说用户数据库疑似泄露登录日志里全是奇怪的SQL语句拼接痕迹最后排查下来就是一个老项目里用了字符串拼接的Statement被攻击者用‘ or ‘1’‘1这种经典手法给绕过去了。还有一次一个内容展示页面被嵌入了恶意脚本用户一点开Cookie就被悄无声息地发到了攻击者的服务器上。这些事儿没摊上觉得是危言耸听摊上了就是P0级故障。所以今天我们不谈那些空泛的“安全重要性”就扎扎实实地聊两个在Java Web开发中最常见、也最容易被忽视的漏洞SQL注入和跨站脚本攻击。这不仅仅是面试八股文里的常客更是每个一线开发者每天写代码时都应该绷紧的一根弦。很多人觉得用了MyBatis、Spring Data JPA就高枕无忧了其实不然错误的使用姿势照样会打开安全的大门。这篇文章我会结合我踩过的坑和修复过的案例从攻击原理、到代码层面的防御、再到框架的最佳实践给你讲透、讲明白。目标就一个让你看完之后不仅能回答面试官更能写出让运维兄弟睡个安稳觉的代码。2. 核心攻击原理拆解知己知彼百战不殆在动手修复之前我们得先搞清楚敌人在怎么进攻。一知半解的安全配置往往是最危险的。2.1 SQL注入你的数据库是如何被“一句话”攻破的SQL注入的本质是攻击者将恶意的SQL代码“注入”到应用程序原本的SQL查询语句中从而欺骗数据库服务器执行非预期的操作。它的核心前提是程序将用户输入的数据未经充分处理直接拼接到了SQL语句里。我们来看一个最经典的漏洞代码String username request.getParameter(“username”); String password request.getParameter(“password”); String sql “SELECT * FROM users WHERE username ‘“ username “‘ AND password ‘“ password “‘“; Statement stmt connection.createStatement(); ResultSet rs stmt.executeQuery(sql);看起来很正常对吧但如果用户在用户名输入框里输入的不是“zhangsan”而是‘ OR ‘1’‘1’ --那么拼接出来的SQL语句就变成了SELECT * FROM users WHERE username ‘’ OR ‘1’‘1’ -- ‘ AND password ‘xxx’这里‘提前闭合了username的字符串OR ‘1’‘1’使得WHERE条件永远为真而--在大多数数据库中是注释符它会把后面所有的语句包括密码检查都注释掉。结果就是攻击者无需知道密码就能以第一个用户的身份登录系统。这还只是入门级。更危险的攻击包括联合查询注入利用UNION关键字窃取其他表的数据。布尔盲注通过页面返回的真假差异一点点“猜”出数据库内容。时间盲注利用SLEEP()等函数通过响应时间差异来判断条件真假。堆叠查询执行多条SQL语句进行增删改甚至删除表等破坏性操作。注意很多新手会误以为过滤了“空格”、“引号”就安全了。攻击者会用/**/代替空格用CHAR(39)代替单引号绕过简单的过滤。永远不要试图通过黑名单过滤特定字符来防御SQL注入这是条死路。2.2 XSS攻击当你的页面成了攻击者的“扩音器”XSS全称跨站脚本攻击。它的原理是攻击者将恶意脚本代码“注入”到目标网页中当其他用户浏览该网页时嵌入的脚本就会被执行。与SQL注入攻击服务器不同XSS的最终受害者是访问网页的用户。根据恶意脚本的存储和触发位置主要分为三类反射型XSS最常见也常与钓鱼结合。恶意脚本作为请求的一部分比如在URL参数中服务器直接“反射”回响应页面中执行。攻击场景攻击者构造一个包含恶意脚本的链接如http://victim-site/search?keywordscriptalert(document.cookie)/script然后通过邮件、论坛诱骗用户点击。用户一旦点击脚本就在其浏览器中执行可能盗取其在该网站的Cookie。存储型XSS危害最大。恶意脚本被永久地存储到服务器端如数据库、文件系统当任何用户访问包含该数据的页面时脚本都会被加载执行。攻击场景论坛的帖子、用户昵称、商品评论框。攻击者提交一段带脚本的评论保存到数据库。此后所有浏览这条评论的用户都会中招。著名的“微博蠕虫”就是利用存储型XSS进行传播的。DOM型XSS一种前端漏洞。恶意脚本的注入和解析完全发生在客户端的DOM树操作过程中不经过服务器。攻击场景页面上的JavaScript代码从location.hash、document.referrer等用户可控的来源获取数据并直接使用innerHTML或eval()等危险方法进行处理。例如scripteval(location.hash.substring(1));/script如果URL是#alert(1)就会触发。XSS的危害远不止弹个警告框。它能盗取用户会话Cookie实现身份冒充。发起伪造请求CSRF以用户身份执行操作如转账、改密。劫持用户浏览器进行键盘记录、钓鱼。植入木马传播蠕虫。实操心得防御XSS核心思路就一条“对不可信的数据进行输出编码”。但具体在哪里编码、怎么编码取决于数据最终被放入的上下文HTML、JavaScript、CSS、URL。用错地方等于没防。3. 防御实战从框架到代码的层层布防知道了原理我们就在每个可能出问题的环节筑起防线。安全是一个体系不是某个孤立的特性。3.1 根治SQL注入告别拼接拥抱预编译防御SQL注入最有效、最根本的方法是使用参数化查询在Java中主要体现为PreparedStatement。它的原理是将SQL语句的结构与数据分离。SQL语句模板先被发送到数据库进行编译用户输入的数据随后作为“参数”传入数据库会严格将其视为数据而非可执行代码的一部分。正确做法示例String sql “SELECT * FROM users WHERE username ? AND password ?“; PreparedStatement pstmt connection.prepareStatement(sql); pstmt.setString(1, username); // 参数1 类型为String pstmt.setString(2, password); // 参数2 类型为String ResultSet rs pstmt.executeQuery();无论username参数传入‘ OR ‘1’‘1’ --还是其他任何内容它都会被当作一个完整的字符串值去和username字段比较而不会改变SQL语句的原有结构。在ORM框架中的使用要点MyBatis必须使用#{} 禁止使用${}进行参数拼接。#{}在底层会生成PreparedStatement的参数占位符?是安全的。${}是直接的字符串替换存在SQL注入风险仅能用于动态指定列名、表名等无法参数化的场景且使用时必须对输入进行严格白名单校验。!-- 安全 -- select id“getUser” resultType“User” SELECT * FROM user WHERE name #{name} /select !-- 危险除非‘orderByColumn’经过严格校验 -- select id“getUser” resultType“User” SELECT * FROM user ORDER BY ${orderByColumn} /selectSpring Data JPA / Hibernate使用Query注解时同样要使用参数绑定。// 安全位置参数 Query(“SELECT u FROM User u WHERE u.username ?1 AND u.email ?2“) User findByUsernameAndEmail(String username, String email); // 安全命名参数更推荐 Query(“SELECT u FROM User u WHERE u.username :uname AND u.email :email“) User findByUsernameAndEmail(Param(“uname”) String username, Param(“email”) String email); // 危险字符串拼接错误示范 Query(“SELECT u FROM User u WHERE u.username ‘“ “:username” “‘“) // 错误 User findUserUnsafe(String username);使用Criteria API或QueryDSL进行动态查询它们是类型安全的天生免疫SQL注入。注意事项PreparedStatement并非绝对银弹。如果参数值本身用于动态拼接SQL逻辑如ORDER BY后面的列名、表名依然需要谨慎处理。这时应使用白名单机制只允许预定义的、安全的选项。// 白名单校验示例 private static final SetString SAFE_SORT_COLUMNS Set.of(“createTime”, “username”, “id”); String sortBy request.getParameter(“sortBy”); if (!SAFE_SORT_COLUMNS.contains(sortBy)) { sortBy “createTime”; // 默认值 } String sql “SELECT * FROM products ORDER BY “ sortBy; // 此时拼接相对安全3.2 全面防御XSS输入过滤与输出编码的双重保险XSS防御需要前后端配合遵循“外部数据皆不可信”的原则。3.2.1 后端防御在数据输出前进行编码/过滤HTML实体编码这是防御XSS最基础、最重要的一环。当用户输入的数据需要作为文本内容Text Content显示在HTML标签内部时必须进行HTML实体编码。作用将具有特殊HTML语义的字符如,,,“,’转换为其对应的实体如lt;,gt;,amp;,quot;,#x27;。这样浏览器会将其解析为普通文本而不是HTML标签或属性。Java实现可以使用Apache Commons Lang的StringEscapeUtils.escapeHtml4()或者更现代的OWASP Java Encoder库。import org.owasp.encoder.Encode; String userInput “scriptalert(‘xss’)/script“; String safeOutput Encode.forHtmlContent(userInput); // safeOutput 变为lt;scriptgt;alert(#x27;xss#x27;)lt;/scriptgt; // 在页面上会原样显示为文本而不是执行脚本。上下文相关的编码编码不是一成不变的取决于数据被放置的“上下文”。HTML属性上下文数据放在HTML标签的属性值里如input value“${data}”。需要使用Encode.forHtmlAttribute()。它除了处理HTML特殊字符还会处理属性值引号。JavaScript上下文数据需要嵌入到script标签内。必须使用Encode.forJavaScript()它会转义JS中的特殊字符如引号、换行符和Unicode转义。URL上下文数据作为URL的一部分如a href“/profile?name${data}”。需要使用Encode.forUriComponent()类似JavaScript的encodeURIComponent。CSS上下文极少见但如果需要使用Encode.forCssString()。使用安全的富文本处理对于评论、文章等需要保留部分HTML格式如加粗、斜体的场景不能简单地进行HTML编码那会连合法的格式也破坏掉。此时必须使用严格的“白名单”策略进行HTML过滤。推荐工具Jsoup是一个优秀的HTML解析和清理库。import org.jsoup.Jsoup; import org.jsoup.safety.Safelist; String dirtyHtml “pa href‘http://example.com/‘ onclick‘stealCookies()’Link/ascriptalert(‘bad’)/script/p“; // 定义一个相对宽松但安全的白名单允许p、a、b、i等标签以及a标签的href属性 Safelist whitelist Safelist.relaxed() .addProtocols(“a”, “href”, “http”, “https”) // 只允许http/https链接 .removeAttributes(“a”, “onclick”); // 移除危险的事件属性 String cleanHtml Jsoup.clean(dirtyHtml, whitelist); // cleanHtml 结果为pa href“http://example.com/“Link/a/p // 脚本、onclick事件都被过滤掉了。3.2.2 前端辅助防御内容安全策略CSP是一种由浏览器提供的、声明式的安全层它告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行是防御XSS的终极利器。原理通过HTTP响应头Content-Security-Policy来定义策略。即使攻击者成功注入了脚本如果该脚本的来源不在白名单内浏览器也会拒绝执行。示例策略Content-Security-Policy: default-src ‘self’; script-src ‘self’ https://trusted.cdn.com; style-src ‘self’ ‘unsafe-inline’; img-src *;default-src ‘self’默认只允许加载同源资源。script-src ‘self’ https://trusted.cdn.com脚本只允许来自同源和指定的CDN。style-src ‘self’ ‘unsafe-inline’样式允许同源和内联谨慎使用。img-src *图片可以从任何地方加载。在Spring Boot中配置Configuration public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http // ... 其他配置 .headers() .contentSecurityPolicy(“default-src ‘self’; script-src ‘self’; style-src ‘self’;”); } }实操心得输出编码的时机比过滤更重要。我个人倾向于在视图层如Thymeleaf、JSP、FreeMarker模板或序列化层如返回JSON的Controller进行编码。因为数据在系统内部流转时可能需要保持原始格式过早编码可能会破坏数据。像Thymeleaf模板引擎默认就会对${...}表达式进行HTML转义这为我们提供了很好的默认安全防护。4. 框架级安全增强与最佳实践除了基础的编码和参数化查询现代Java生态提供了更强大的安全工具。4.1 使用Spring Security进行深度防护Spring Security不仅仅用于认证授权它提供了全面的Web安全防护。自动CSRF防护Spring Security默认会为状态改变的请求POST, PUT, DELETE等启用CSRF令牌保护有效防御跨站请求伪造攻击这是XSS攻击常常结合利用的手段。安全响应头除了CSP还可以方便地配置其他安全头如X-Content-Type-Options: nosniff阻止浏览器MIME类型嗅探。X-Frame-Options: DENY防止页面被嵌入到iframe中点击劫持。Strict-Transport-Security强制使用HTTPS。http.headers() .contentSecurityPolicy(“...“) .frameOptions().deny() .httpStrictTransportSecurity() .includeSubDomains(true) .maxAgeInSeconds(31536000);4.2 依赖安全扫描守住第三方库的入口你的应用安全你的依赖库不一定安全。像Log4j2漏洞这种由第三方库引发的“核弹级”问题必须通过工具来防范。工具推荐OWASP Dependency-Check或GitHub Dependabot、Snyk。集成到Maven构建流程plugin groupIdorg.owasp/groupId artifactIddependency-check-maven/artifactId version8.4.2/version executions execution goals goalcheck/goal /goals /execution /executions /plugin作用在编译或CI/CD流程中自动分析项目依赖比对已知漏洞数据库如NVD生成报告提示存在安全风险的库及其修复版本。4.3 实施安全的API设计对于前后端分离的应用API是主要入口其安全设计至关重要。输入验证使用Bean ValidationValid,NotNull,Size,Pattern在Controller入口处对DTO进行强验证。public class UserDTO { NotBlank Size(min3, max50) private String username; Email private String email; Pattern(regexp “^[a-zA-Z0-9]{6,20}$“) // 限制密码格式 private String password; } PostMapping(“/users“) public ResponseEntity createUser(Valid RequestBody UserDTO userDto) { // ... 业务逻辑 }输出净化在返回JSON数据前对字符串字段进行适当的编码或清理防止JSON劫持或通过API响应的XSS。可以结合Jackson的序列化器或AOP实现全局处理。速率限制对登录、注册、验证码请求等接口实施速率限制防止暴力破解和DoS攻击。可以使用Spring Boot整合Redis轻松实现。5. 常见问题排查与实战调试技巧理论懂了代码写了但线上还是可能出问题。下面是一些我实践中总结的排查思路和技巧。5.1 SQL注入漏洞排查清单当你怀疑某个接口存在SQL注入时可以按以下步骤排查代码审查全局搜索项目中Statement、executeUpdate、executeQuery与字符串拼接同时出现的地方。重点审查动态SQL构建的逻辑。MyBatis XML检查搜索所有${}的使用场景确认其参数是否完全可控且未经验证。日志分析开启数据库的查询日志注意性能影响观察执行的SQL语句是否包含异常的拼接参数。在测试环境可以临时开启MyBatis的SQL日志打印。# application.yml for MyBatis logging: level: com.xxx.mapper: debug # 打印执行的SQL和参数自动化工具扫描使用SQLMap仅用于授权测试对测试环境接口进行自动化探测。它可以帮你快速确认是否存在注入点以及注入类型。5.2 XSS漏洞手动测试与验证防御措施是否生效需要测试。基础Payload测试scriptalert(‘XSS’)/script最基础的测试。img src“x” onerror“alert(1)”利用图片加载错误事件。svg onload“alert(1)”利用SVG标签。“scriptalert(1)/script尝试闭合前一个属性或标签。上下文测试如果输入点出现在input value“${here}”尝试输入“ onmouseover“alert(1)。如果输入点出现在scriptvar data ‘${here}’; /script尝试输入’; alert(1); //。观察输出在浏览器中右键“查看页面源代码”搜索你的测试输入看它是否被原样输出危险还是被转义成了HTML实体安全。使用浏览器开发者工具的“元素”面板查看动态生成的DOM结构确认事件属性等是否被成功注入。CSP有效性测试尝试注入一个来自外部域的脚本如script src“http://evil.com/bad.js”/script。观察浏览器控制台是否出现CSP违规报告。5.3 安全编码 checklist在代码审查或自己编写代码时心里默念这个清单场景安全实践风险点数据库操作一律使用PreparedStatement或ORM框架的参数绑定#{},?。使用字符串拼接SQL。动态表名/列名使用白名单校验或从枚举/配置中获取。直接使用用户输入拼接。日志记录对用户输入进行过滤后再记录防止日志注入。将未经验证的请求参数直接写入日志文件。HTML输出根据上下文内容、属性、JS、CSS使用对应的编码函数。直接使用${userInput}输出到模板。富文本处理使用Jsoup等库进行基于白名单的HTML过滤。使用黑名单或简单的正则过滤。JSON输出确保JSON序列化器能正确处理特殊字符或提前编码。手动拼接JSON字符串。重定向/跳转校验目标URL是否属于允许的域名白名单。直接使用用户输入的URL进行重定向。文件上传校验文件类型后缀、MIME类型、大小重命名存储。信任客户端传来的文件名和类型。错误信息向用户展示友好的通用错误信息而非详细的异常堆栈。将数据库错误、Java异常直接返回给前端。5.4 线上监控与应急响应安全是持续的过程需要监控和预案。监控异常SQL在应用层或数据库层部署监控对执行时间异常长、执行频率异常高、或包含特定敏感关键词如union select,sleep(,information_schema的SQL语句进行告警。WAF在应用前端部署Web应用防火墙它可以基于规则库拦截常见的SQL注入、XSS等攻击请求为应用提供一道额外的缓冲层。但记住WAF不能替代安全的代码它是补充不是根本。应急响应一旦发现漏洞被利用立即隔离通过WAF或网关快速封禁攻击源IP。止血评估漏洞点进行临时代码修复或配置调整如加强过滤规则。排查分析日志确定受影响的数据范围和用户。修复与发布完成根本原因修复并进行安全测试后上线。通知与复盘根据法规要求通知受影响用户并进行内部技术复盘避免同类问题。安全这件事没有一劳永逸。它要求我们在写每一行代码时都保持警惕在每一次代码审查时都多问一句“这里安全吗”在每一次技术选型时都把安全特性纳入考量。从使用PreparedStatement代替拼接到在模板里习惯性地做输出编码这些细微的习惯积累起来就是你的应用最坚固的铠甲。