1. 项目概述为什么Java Web安全是每个开发者的必修课最近在帮一个朋友的公司做代码审计他们刚上线一个内部管理系统用的是典型的JavaWeb技术栈。我随手翻了几个JSP页面就发现了好几个地方直接把用户输入的内容用% request.getParameter(name) %的方式输出到了页面上。我问他“这里不怕XSS吗”他愣了一下说“这是内部系统用户都是同事应该没事吧”我当场写了个简单的Payload在他的系统里弹了个窗他脸色立刻就变了。这个场景太常见了无论是刚入行的新手还是工作了几年的开发者对Web安全的理解往往停留在“听说过”的层面总觉得攻击离自己很远或者觉得框架已经帮我们处理好了。但现实是框架提供的安全防护是基础性的、可配置的如果你不了解其原理和配置方式就等于在裸奔。XSS跨站脚本攻击和CSRF跨站请求伪造是Web领域最古老、最经典也最高频的两类攻击。说它们古老是因为从有动态网页开始这两种攻击形式就存在了说它们高频是因为直到今天它们依然是OWASP Top 10榜单上的常客无数漏洞报告都源于此。这个项目我们就来彻底搞懂在JavaWeb环境中如何从原理到实践系统地防御XSS与CSRF攻击。这不是一个简单的“配置某个过滤器”的教程而是带你理解攻击是如何发生的现有的防护机制如Spring Security是如何工作的以及当标准方案不适用时我们如何自己动手构建防线。无论你是在用传统的Servlet/JSP还是主流的Spring Boot甚至是更古老的Struts2这里面的核心思想都是相通的。安全不是运维或安全工程师的专属它是每一位编写对外提供服务的代码的开发者的责任。2. 攻击原理深度拆解知己知彼百战不殆在开始砌墙之前我们必须先看清楚攻击者是从哪里挖洞的。很多防御措施之所以失效就是因为对攻击原理一知半解只做了表面功夫。2.1 XSS攻击当你的页面“活”了过来XSS的本质是“注入”攻击者将恶意脚本“注入”到原本受信任的网页中当其他用户浏览该网页时嵌入其中的脚本就会被执行。根据脚本注入和执行的“位置”与“时机”XSS主要分为三类它们的防御侧重点截然不同。反射型XSS这是最常见、也最容易被理解的一种。攻击过程通常是这样攻击者构造一个包含恶意脚本的URL然后通过邮件、论坛等方式诱骗用户点击。服务器接收到这个请求后未加处理就将恶意参数拼接进响应页面并返回给用户的浏览器脚本随即执行。例如一个搜索功能%-- 危险的JSP代码 --% 您的搜索关键词是% request.getParameter(keyword) %攻击者发送链接http://target.com/search?keywordscriptalert(xss)/script。用户点击后脚本就会在其浏览器中执行。反射型XSS的恶意代码在URL中是一次性的不存储在服务器上。存储型XSS这是危害最大的一种。攻击者将恶意脚本提交到网站的后端数据库如论坛发帖、用户评论、个人简介字段当其他用户浏览包含这些数据的页面时脚本就会被加载并执行。例如一个评论系统未对评论内容做过滤攻击者提交了一条包含scriptstealCookie()/script的评论。此后所有查看该评论页面的用户都会中招他们的会话Cookie可能被窃取。存储型XSS的恶意代码持久化在服务器上影响所有访问者。DOM型XSS这是一种纯前端的攻击恶意代码的注入和执行完全在浏览器端的DOM解析环境中完成不经过服务器。漏洞源于不安全的JavaScript代码对用户可控数据如location.hash、document.referrer、URL参数的处理。例如// 危险的JavaScript代码 var userInput window.location.hash.substring(1); document.getElementById(message).innerHTML Welcome, userInput;如果URL是http://target.com#img src1 onerroralert(1)那么onerror事件就会被触发。DOM型XSS的难点在于它绕过了服务端的过滤因为恶意Payload在到达服务器时可能只是URL的一部分服务器返回的是正常的HTML和JS是浏览器自己的解析逻辑导致了问题。注意很多人认为用了JSTL的c:out或者Thymeleaf就高枕无忧了这只能防御反射型和存储型XSS中简单的HTML注入。对于hrefjavascript:alert(1)这种属性注入或者复杂的DOM型XSS后端模板引擎常常无能为力需要前后端协同防御。2.2 CSRF攻击冒充用户的“合法”请求CSRF攻击的原理比XSS更“狡猾”。它利用的是Web应用对用户浏览器的完全信任。攻击者盗用了用户的身份以Cookie或Session形式存在以用户的名义发送恶意请求。想象这样一个场景你登录了网上银行站点A浏览器保存了你的登录会话Cookie。此时你不小心访问了一个恶意网站站点B。这个恶意网站的页面上隐藏着一个自动提交的表单或者一个img标签其src指向的是网上银行的转账接口并附带了转账参数。!-- 恶意网站B上的代码 -- img srchttp://bank.com/transfer?toattackeramount10000 width0 height0 /由于你的浏览器在访问bank.com时会自动携带该域下的登录Cookie银行服务器看到的是一个带有合法会话凭证的请求便会正常执行转账操作。在整个过程中攻击者并不知道你的Cookie具体是什么他只是利用了浏览器自动发送Cookie的机制。CSRF攻击成功的核心条件有三个用户已登录受信任网站A并生成了本地Cookie。用户在不登出A的情况下访问了危险网站B。网站A的接口没有做任何CSRF防护它只认Cookie/Session不关心请求的来源。与XSS盗取Cookie主动发起请求不同CSRF是“借刀杀人”让用户的浏览器在不知情的情况下以用户的权限去执行操作。3. 防御体系构建从全局到局部的纵深防护理解了攻击原理我们就可以有针对性地构建防御体系。安全的黄金法则是不信任任何用户输入也不假定自己的输出环境是安全的。防御不是单一技术点而是一个从数据流入到流出的完整链条。3.1 对抗XSS输入过滤、输出编码与内容安全策略第一道防线输入验证与过滤在数据进入应用逻辑的第一时间进行验证和过滤这是一个好习惯但绝不能作为唯一的防线。对于明确的格式要求如邮箱、电话、数字使用白名单策略进行严格校验。对于富文本等需要保留部分HTML的场景过滤是必须的。实践建议使用成熟的HTML过滤库如OWASP Java HTML Sanitizer。它允许你定义一个白名单指定允许的标签和属性其他一律过滤掉。自己写正则表达式过滤HTML是极其危险且容易绕过的。// 使用OWASP Java HTML Sanitizer示例 PolicyFactory policy new HtmlPolicyBuilder() .allowElements(a, p, div, strong, em) .allowAttributes(href).onElements(a) .requireRelNofollowOnLinks() // 强制为链接添加nofollow .toFactory(); String safeHtml policy.sanitize(userInput);核心防线输出编码这是防御反射型和存储型XSS最有效、最根本的手段。其原则是将数据输出到不同的上下文时进行针对该上下文的编码。HTML正文编码将,,,,等字符转换为HTML实体如-lt;。在JSP中务必使用JSTL的c:out标签它默认就会进行HTML编码。%-- 安全 --% p用户名c:out value${user.name}//p %-- 危险 --% p用户名${user.name}/pHTML属性编码除了上述字符空格和引号也需要根据情况处理。c:out在属性中同样有效。在纯JavaScript中构造HTML时也要进行编码。JavaScript上下文编码当需要将Java变量输出到script标签内时情况变得复杂。简单的HTML编码在这里无效因为浏览器会先解码HTML实体再执行JS。正确的做法是进行JavaScript Unicode转义如\u003c或使用JSON序列化。script // 危险如果userInput是 ; alert(1);// var userData % request.getParameter(input) %; // 安全使用JSTL并注意引号 var userData c:out value${param.input}/; // 更安全将数据放在HTML的data-*属性中再用JS读取 /scriptURL编码当用户输入作为URL的一部分如查询参数、href属性时必须进行URL编码java.net.URLEncoder。高级防线内容安全策略CSP是一个由浏览器提供的、声明式的安全层它告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行。即使网站存在XSS漏洞攻击者注入的脚本如果不在CSP允许的源列表中浏览器也不会执行。如何实施通过HTTP响应头Content-Security-Policy来设置。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;这个策略表示默认只允许同源资源脚本只允许同源和https://trusted.cdn.com样式允许同源和内联样式unsafe-inline。启用CSP能极大缓解XSS的影响是现代Web应用的标配。针对DOM型XSS的防御避免不安全的DOM操作尽量避免使用innerHTML、outerHTML、document.write()等能直接解析HTML字符串的方法。优先使用textContent或innerText来设置文本内容。对来自URL或用户输入的数据进行客户端编码如果必须动态操作DOM对于要插入到HTML上下文的数据使用createElement和appendChild对于要作为属性值的数据使用setAttribute。使用安全的API例如使用input.value而不是拼接字符串来构造URL。3.2 对抗CSRF令牌验证、同源检测与双重认证最主流方案CSRF Token这是目前防御CSRF最有效、最通用的方法。原理是在用户会话中生成一个随机、不可预测的令牌Token在渲染表单或页面时将其嵌入如作为隐藏字段在提交请求时要求携带此令牌服务器端进行验证。服务端实现要点生成与存储用户登录或访问页面时在服务端Session中生成一个强随机数Token。下发在渲染表单时将Token放入一个隐藏的input字段中或者作为meta标签放入页面头部供前端JS读取。验证对于需要防护的请求POST、PUT、DELETE等服务器检查请求参数或头如X-CSRF-TOKEN中的Token是否与Session中存储的一致。验证成功后可以更新Token同步令牌模式或保持原样。Spring Security的集成Spring Security默认就提供了CSRF防护。它会自动生成Token并在form:form标签中自动添加_csrf隐藏域。对于Ajax请求你需要从meta标签或Cookie中获取Token并在请求头中携带。注意在纯API如RESTful且使用无状态认证如JWT的场景下需要仔细评估是否禁用CSRF防护因为其攻击前提浏览器自动携带Cookie可能已不存在。辅助方案检查请求头利用浏览器同源策略的限制由JavaScript发起的跨域请求如通过Fetch API或XMLHttpRequest可以自定义请求头但简单的跨站请求如form提交、img加载则不能。因此我们可以要求敏感请求必须携带一个自定义头如X-Requested-With: XMLHttpRequest并在服务端验证。但这只能作为辅助手段因为攻击者可能通过某些方式如Flash绕过此限制。利用SameSite Cookie属性这是一个由浏览器实现的、从源头遏制CSRF的Cookie属性。通过设置Set-Cookie: SessionIdabc123; SameSiteStrict可以告诉浏览器仅在“同站”请求即请求的站点与Cookie的站点一致中才发送此Cookie。SameSiteStrict最严格完全禁止第三方上下文携带Cookie。可能导致从其他网站链接过来的用户需要重新登录。SameSiteLax宽松模式允许在顶级导航如点击链接和GET请求中携带Cookie但禁止在跨站POST请求或通过iframe等嵌入的请求中携带。这是目前很多站点的默认推荐值。SameSiteNone等同于旧行为允许跨站携带但必须同时设置Secure属性即仅限HTTPS。关键操作使用二次验证对于转账、修改密码、删除数据等极高危操作强制要求用户进行二次验证如输入密码、短信验证码、生物识别等。这虽然不是纯粹的CSRF防御但能从业务逻辑上彻底杜绝此类攻击因为攻击者无法获知用户的二次验证凭证。4. 在JavaWeb项目中的具体实现与配置理论说再多不如一行代码。下面我们分别看在Servlet/JSP项目和Spring Boot项目中如何具体落地这些防御措施。4.1 传统Servlet/JSP项目实战在没有框架加持的情况下我们需要手动构建防护层。防御XSS自定义过滤器与JSTL创建XSS防御过滤器虽然核心是输出编码但一个全局的请求参数过滤过滤器可以作为补充防线。WebFilter(/*) public class XSSFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { chain.doFilter(new XSSRequestWrapper((HttpServletRequest) request), response); } // XSSRequestWrapper 需要重写 getParameter, getParameterValues, getHeader 等方法 // 对获取到的字符串进行HTML转义。注意此方法可能误伤合法数据需谨慎设计过滤规则。 // 更推荐的做法是仅在此处进行简单的危险字符检查或日志记录核心防御放在输出端。 }强制使用JSTL进行输出在团队规范中明确所有JSP页面禁止使用% %脚本表达式输出动态内容一律使用c:out。设置响应安全头在过滤器中或单独的Filter里设置CSP和X-Content-Type-Options等头。httpResponse.setHeader(Content-Security-Policy, default-src self;); httpResponse.setHeader(X-Content-Type-Options, nosniff); // 禁止浏览器MIME嗅探 httpResponse.setHeader(X-Frame-Options, DENY); // 禁止页面被iframe嵌入防点击劫持防御CSRF手动实现Token机制生成Token工具类public class CSRFTokenUtil { private static final SecureRandom secureRandom new SecureRandom(); public static String generateToken() { byte[] bytes new byte[16]; secureRandom.nextBytes(bytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes); } public static void storeToken(HttpSession session, String tokenKey) { session.setAttribute(tokenKey, generateToken()); } public static String getToken(HttpSession session, String tokenKey) { return (String) session.getAttribute(tokenKey); } public static boolean isValid(HttpServletRequest req, String tokenKey) { String sessionToken getToken(req.getSession(false), tokenKey); String requestToken req.getParameter(tokenKey); return sessionToken ! null sessionToken.equals(requestToken); } }应用Token在展示表单的Servlet中生成Token并存入Session同时传递给JSP。CSRFTokenUtil.storeToken(request.getSession(), csrfToken); request.setAttribute(csrfToken, CSRFTokenUtil.getToken(request.getSession(), csrfToken));在JSP表单中添加隐藏域。input typehidden namecsrfToken value${csrfToken}在处理表单提交的Servlet中验证Token。if (!CSRFTokenUtil.isValid(request, csrfToken)) { throw new SecurityException(CSRF token validation failed.); } // 验证通过后可以移除或更新旧Token4.2 Spring Boot项目集成实践Spring Boot Spring Security让安全配置变得声明式和模块化。防御XSS依赖库与配置输入过滤在Controller层使用Valid注解配合JSR-303校验注解如NotBlank,Email。对于复杂过滤在Service层引入OWASP Java HTML Sanitizer。输出编码Thymeleaf模板Thymeleaf默认会对所有th:text进行HTML转义。对于需要输出原始HTML的情况使用th:utext要极其小心确保内容绝对安全。前后端分离后端API返回JSON数据前端负责渲染。这时XSS防御的责任主要转移到了前端。后端需要确保JSON中的字符串不包含未转义的HTML/JS。前端框架如React、Vue默认会对绑定到模板的数据进行转义。配置安全响应头在application.properties或通过配置类设置。# 示例设置CSP头 (通过Spring Security配置更佳) # security.headers.content-security-policydefault-src self防御CSRFSpring Security的自动化防护Spring Security默认启用CSRF防护。你需要了解的是如何与之协作。Thymeleaf表单使用th:action和Spring Security的标签库Token会自动添加。form th:action{/do-something} methodpost !-- Spring Security会自动在此处插入一个名为 _csrf 的隐藏input -- input typesubmit valueSubmit/ /formAjax请求需要手动获取Token并添加到请求头中。Spring Security通常将Token存放在meta标签或Cookie中。// 从meta标签获取 var token document.querySelector(meta[name_csrf]).getAttribute(content); var header document.querySelector(meta[name_csrf_header]).getAttribute(content); // 使用Fetch或Axios发送请求时设置请求头 fetch(/api/endpoint, { method: POST, headers: { Content-Type: application/json, [header]: token // 动态设置头名 }, body: JSON.stringify(data) });自定义与禁用如果需要自定义Token仓库或验证逻辑可以配置CsrfTokenRepository。对于纯无状态API可以考虑禁用CSRF。Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) // 将Token存在Cookie中供JS读取 // .ignoringRequestMatchers(/api/public/**) // 忽略某些路径 // .disable() // 谨慎禁用 ) // ... 其他配置 return http.build(); } }5. 进阶安全编码习惯、测试与漏洞挖掘防御措施是盾良好的编码习惯和主动测试则是打造盾牌的工艺。5.1 必须养成的安全编码习惯明确数据边界时刻清楚一段数据来自哪里不可信的用户输入、可信的内部系统、配置文件以及它要到哪里去HTML页面、SQL语句、操作系统命令、日志文件。针对不同的“去处”采取相应的编码或过滤。使用安全API优先使用提供自动转义或参数化功能的API。数据库永远使用PreparedStatement而不是字符串拼接SQL。执行命令避免Runtime.exec(String command)使用传递字符串数组的版本。文件路径使用PathAPI进行规范化防止路径遍历。最小化暴露Cookie设置HttpOnly和Secure属性。HttpOnly使Cookie无法被JavaScript访问能有效缓解XSS盗取Cookie的风险。Secure要求Cookie仅通过HTTPS传输。依赖安全管理定期使用OWASP Dependency-Check或Snyk等工具扫描项目依赖及时更新存在已知漏洞的第三方库。5.2 如何进行安全测试代码审计定期进行代码审查重点关注用户输入点HttpServletRequest.getParameter(),getHeader()、数据输出点JSP/Thymeleaf表达式、response.getWriter().print()、数据库操作、文件操作、命令执行等。黑盒测试手工测试使用浏览器开发者工具手动构造包含scriptalert(1)/script、img srcx onerroralert(1)、javascript:alert(1)等Payload的请求观察响应。工具扫描使用Burp Suite、OWASP ZAP等渗透测试工具进行自动化的漏洞扫描。它们可以爬取网站并自动尝试各种XSS和CSRF的Payload。CSRF测试手动创建一个简单的HTML页面包含一个指向你站点敏感接口的form或img标签在已登录目标站点的情况下打开这个HTML页面看请求是否会成功执行。或者使用Burp Suite的“生成CSRF PoC”功能。5.3 常见问题与排查实录问题1启用了Spring Security的CSRF防护后我的登录/注销POST请求被拒绝了。原因登录和注销表单也需要CSRF Token。Spring Security的默认登录/注销页面会自动处理。但如果你自定义了登录页面必须手动将Token放入表单。解决在自定义登录页面的表单中添加input typehidden th:name${_csrf.parameterName} th:value${_csrf.token} /。确保登录请求的URL也被包含在CSRF防护中默认是包含的。问题2我的API接收JSON格式的POST请求CSRF Token应该放在哪里原因CSRF Token传统上放在表单字段或请求头中。对于JSON请求无法放在请求体里因为Body已经是JSON格式。解决标准做法是将Token放在HTTP请求头中例如X-CSRF-TOKEN。前端需要在发起请求前从Cookie或Meta标签获取Token并设置到Header里。Spring Security的CookieCsrfTokenRepository策略就是为方便这种场景设计的。问题3使用了c:out但某些地方还是出现了XSS。排查检查是否错误地使用了c:out escapeXmlfalse这关闭了转义功能非常危险。检查输出点是否不在HTML正文而是在JavaScript代码块内、HTML标签的属性内尤其是href、src、onclick等事件属性。对于这些上下文c:out的HTML编码可能不够。检查是否是DOM型XSS。查看页面JavaScript代码是否有eval()、setTimeout()、innerHTML直接使用了来自URLlocation.hash或用户输入的数据。问题4CSP策略太严格导致我的页面样式或脚本加载失败。解决CSP策略应该采用逐步收紧的策略。首先设置一个仅报告而不拦截的策略头Content-Security-Policy-Report-Only并配置report-uri或report-to指令来收集违规报告。分析报告了解页面正常运行需要加载哪些资源。根据报告逐步完善和收紧CSP策略最后将-Report-Only后缀去掉正式启用拦截模式。安全是一个持续的过程而不是一个可以一劳永逸的开关。将上述防御措施融入到开发和部署流程中定期进行安全培训和代码审计才能构建起真正有韧性的Web应用。从我个人的经验来看最大的风险往往不是来自高深的技术漏洞而是源于开发者的疏忽和对“内部系统”、“小功能”的侥幸心理。每一次对用户输入的无条件信任都可能为攻击者打开一扇门。
Java Web安全实战：从原理到代码，全面防御XSS与CSRF攻击
1. 项目概述为什么Java Web安全是每个开发者的必修课最近在帮一个朋友的公司做代码审计他们刚上线一个内部管理系统用的是典型的JavaWeb技术栈。我随手翻了几个JSP页面就发现了好几个地方直接把用户输入的内容用% request.getParameter(name) %的方式输出到了页面上。我问他“这里不怕XSS吗”他愣了一下说“这是内部系统用户都是同事应该没事吧”我当场写了个简单的Payload在他的系统里弹了个窗他脸色立刻就变了。这个场景太常见了无论是刚入行的新手还是工作了几年的开发者对Web安全的理解往往停留在“听说过”的层面总觉得攻击离自己很远或者觉得框架已经帮我们处理好了。但现实是框架提供的安全防护是基础性的、可配置的如果你不了解其原理和配置方式就等于在裸奔。XSS跨站脚本攻击和CSRF跨站请求伪造是Web领域最古老、最经典也最高频的两类攻击。说它们古老是因为从有动态网页开始这两种攻击形式就存在了说它们高频是因为直到今天它们依然是OWASP Top 10榜单上的常客无数漏洞报告都源于此。这个项目我们就来彻底搞懂在JavaWeb环境中如何从原理到实践系统地防御XSS与CSRF攻击。这不是一个简单的“配置某个过滤器”的教程而是带你理解攻击是如何发生的现有的防护机制如Spring Security是如何工作的以及当标准方案不适用时我们如何自己动手构建防线。无论你是在用传统的Servlet/JSP还是主流的Spring Boot甚至是更古老的Struts2这里面的核心思想都是相通的。安全不是运维或安全工程师的专属它是每一位编写对外提供服务的代码的开发者的责任。2. 攻击原理深度拆解知己知彼百战不殆在开始砌墙之前我们必须先看清楚攻击者是从哪里挖洞的。很多防御措施之所以失效就是因为对攻击原理一知半解只做了表面功夫。2.1 XSS攻击当你的页面“活”了过来XSS的本质是“注入”攻击者将恶意脚本“注入”到原本受信任的网页中当其他用户浏览该网页时嵌入其中的脚本就会被执行。根据脚本注入和执行的“位置”与“时机”XSS主要分为三类它们的防御侧重点截然不同。反射型XSS这是最常见、也最容易被理解的一种。攻击过程通常是这样攻击者构造一个包含恶意脚本的URL然后通过邮件、论坛等方式诱骗用户点击。服务器接收到这个请求后未加处理就将恶意参数拼接进响应页面并返回给用户的浏览器脚本随即执行。例如一个搜索功能%-- 危险的JSP代码 --% 您的搜索关键词是% request.getParameter(keyword) %攻击者发送链接http://target.com/search?keywordscriptalert(xss)/script。用户点击后脚本就会在其浏览器中执行。反射型XSS的恶意代码在URL中是一次性的不存储在服务器上。存储型XSS这是危害最大的一种。攻击者将恶意脚本提交到网站的后端数据库如论坛发帖、用户评论、个人简介字段当其他用户浏览包含这些数据的页面时脚本就会被加载并执行。例如一个评论系统未对评论内容做过滤攻击者提交了一条包含scriptstealCookie()/script的评论。此后所有查看该评论页面的用户都会中招他们的会话Cookie可能被窃取。存储型XSS的恶意代码持久化在服务器上影响所有访问者。DOM型XSS这是一种纯前端的攻击恶意代码的注入和执行完全在浏览器端的DOM解析环境中完成不经过服务器。漏洞源于不安全的JavaScript代码对用户可控数据如location.hash、document.referrer、URL参数的处理。例如// 危险的JavaScript代码 var userInput window.location.hash.substring(1); document.getElementById(message).innerHTML Welcome, userInput;如果URL是http://target.com#img src1 onerroralert(1)那么onerror事件就会被触发。DOM型XSS的难点在于它绕过了服务端的过滤因为恶意Payload在到达服务器时可能只是URL的一部分服务器返回的是正常的HTML和JS是浏览器自己的解析逻辑导致了问题。注意很多人认为用了JSTL的c:out或者Thymeleaf就高枕无忧了这只能防御反射型和存储型XSS中简单的HTML注入。对于hrefjavascript:alert(1)这种属性注入或者复杂的DOM型XSS后端模板引擎常常无能为力需要前后端协同防御。2.2 CSRF攻击冒充用户的“合法”请求CSRF攻击的原理比XSS更“狡猾”。它利用的是Web应用对用户浏览器的完全信任。攻击者盗用了用户的身份以Cookie或Session形式存在以用户的名义发送恶意请求。想象这样一个场景你登录了网上银行站点A浏览器保存了你的登录会话Cookie。此时你不小心访问了一个恶意网站站点B。这个恶意网站的页面上隐藏着一个自动提交的表单或者一个img标签其src指向的是网上银行的转账接口并附带了转账参数。!-- 恶意网站B上的代码 -- img srchttp://bank.com/transfer?toattackeramount10000 width0 height0 /由于你的浏览器在访问bank.com时会自动携带该域下的登录Cookie银行服务器看到的是一个带有合法会话凭证的请求便会正常执行转账操作。在整个过程中攻击者并不知道你的Cookie具体是什么他只是利用了浏览器自动发送Cookie的机制。CSRF攻击成功的核心条件有三个用户已登录受信任网站A并生成了本地Cookie。用户在不登出A的情况下访问了危险网站B。网站A的接口没有做任何CSRF防护它只认Cookie/Session不关心请求的来源。与XSS盗取Cookie主动发起请求不同CSRF是“借刀杀人”让用户的浏览器在不知情的情况下以用户的权限去执行操作。3. 防御体系构建从全局到局部的纵深防护理解了攻击原理我们就可以有针对性地构建防御体系。安全的黄金法则是不信任任何用户输入也不假定自己的输出环境是安全的。防御不是单一技术点而是一个从数据流入到流出的完整链条。3.1 对抗XSS输入过滤、输出编码与内容安全策略第一道防线输入验证与过滤在数据进入应用逻辑的第一时间进行验证和过滤这是一个好习惯但绝不能作为唯一的防线。对于明确的格式要求如邮箱、电话、数字使用白名单策略进行严格校验。对于富文本等需要保留部分HTML的场景过滤是必须的。实践建议使用成熟的HTML过滤库如OWASP Java HTML Sanitizer。它允许你定义一个白名单指定允许的标签和属性其他一律过滤掉。自己写正则表达式过滤HTML是极其危险且容易绕过的。// 使用OWASP Java HTML Sanitizer示例 PolicyFactory policy new HtmlPolicyBuilder() .allowElements(a, p, div, strong, em) .allowAttributes(href).onElements(a) .requireRelNofollowOnLinks() // 强制为链接添加nofollow .toFactory(); String safeHtml policy.sanitize(userInput);核心防线输出编码这是防御反射型和存储型XSS最有效、最根本的手段。其原则是将数据输出到不同的上下文时进行针对该上下文的编码。HTML正文编码将,,,,等字符转换为HTML实体如-lt;。在JSP中务必使用JSTL的c:out标签它默认就会进行HTML编码。%-- 安全 --% p用户名c:out value${user.name}//p %-- 危险 --% p用户名${user.name}/pHTML属性编码除了上述字符空格和引号也需要根据情况处理。c:out在属性中同样有效。在纯JavaScript中构造HTML时也要进行编码。JavaScript上下文编码当需要将Java变量输出到script标签内时情况变得复杂。简单的HTML编码在这里无效因为浏览器会先解码HTML实体再执行JS。正确的做法是进行JavaScript Unicode转义如\u003c或使用JSON序列化。script // 危险如果userInput是 ; alert(1);// var userData % request.getParameter(input) %; // 安全使用JSTL并注意引号 var userData c:out value${param.input}/; // 更安全将数据放在HTML的data-*属性中再用JS读取 /scriptURL编码当用户输入作为URL的一部分如查询参数、href属性时必须进行URL编码java.net.URLEncoder。高级防线内容安全策略CSP是一个由浏览器提供的、声明式的安全层它告诉浏览器哪些外部资源脚本、样式、图片、字体等可以被加载和执行。即使网站存在XSS漏洞攻击者注入的脚本如果不在CSP允许的源列表中浏览器也不会执行。如何实施通过HTTP响应头Content-Security-Policy来设置。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;这个策略表示默认只允许同源资源脚本只允许同源和https://trusted.cdn.com样式允许同源和内联样式unsafe-inline。启用CSP能极大缓解XSS的影响是现代Web应用的标配。针对DOM型XSS的防御避免不安全的DOM操作尽量避免使用innerHTML、outerHTML、document.write()等能直接解析HTML字符串的方法。优先使用textContent或innerText来设置文本内容。对来自URL或用户输入的数据进行客户端编码如果必须动态操作DOM对于要插入到HTML上下文的数据使用createElement和appendChild对于要作为属性值的数据使用setAttribute。使用安全的API例如使用input.value而不是拼接字符串来构造URL。3.2 对抗CSRF令牌验证、同源检测与双重认证最主流方案CSRF Token这是目前防御CSRF最有效、最通用的方法。原理是在用户会话中生成一个随机、不可预测的令牌Token在渲染表单或页面时将其嵌入如作为隐藏字段在提交请求时要求携带此令牌服务器端进行验证。服务端实现要点生成与存储用户登录或访问页面时在服务端Session中生成一个强随机数Token。下发在渲染表单时将Token放入一个隐藏的input字段中或者作为meta标签放入页面头部供前端JS读取。验证对于需要防护的请求POST、PUT、DELETE等服务器检查请求参数或头如X-CSRF-TOKEN中的Token是否与Session中存储的一致。验证成功后可以更新Token同步令牌模式或保持原样。Spring Security的集成Spring Security默认就提供了CSRF防护。它会自动生成Token并在form:form标签中自动添加_csrf隐藏域。对于Ajax请求你需要从meta标签或Cookie中获取Token并在请求头中携带。注意在纯API如RESTful且使用无状态认证如JWT的场景下需要仔细评估是否禁用CSRF防护因为其攻击前提浏览器自动携带Cookie可能已不存在。辅助方案检查请求头利用浏览器同源策略的限制由JavaScript发起的跨域请求如通过Fetch API或XMLHttpRequest可以自定义请求头但简单的跨站请求如form提交、img加载则不能。因此我们可以要求敏感请求必须携带一个自定义头如X-Requested-With: XMLHttpRequest并在服务端验证。但这只能作为辅助手段因为攻击者可能通过某些方式如Flash绕过此限制。利用SameSite Cookie属性这是一个由浏览器实现的、从源头遏制CSRF的Cookie属性。通过设置Set-Cookie: SessionIdabc123; SameSiteStrict可以告诉浏览器仅在“同站”请求即请求的站点与Cookie的站点一致中才发送此Cookie。SameSiteStrict最严格完全禁止第三方上下文携带Cookie。可能导致从其他网站链接过来的用户需要重新登录。SameSiteLax宽松模式允许在顶级导航如点击链接和GET请求中携带Cookie但禁止在跨站POST请求或通过iframe等嵌入的请求中携带。这是目前很多站点的默认推荐值。SameSiteNone等同于旧行为允许跨站携带但必须同时设置Secure属性即仅限HTTPS。关键操作使用二次验证对于转账、修改密码、删除数据等极高危操作强制要求用户进行二次验证如输入密码、短信验证码、生物识别等。这虽然不是纯粹的CSRF防御但能从业务逻辑上彻底杜绝此类攻击因为攻击者无法获知用户的二次验证凭证。4. 在JavaWeb项目中的具体实现与配置理论说再多不如一行代码。下面我们分别看在Servlet/JSP项目和Spring Boot项目中如何具体落地这些防御措施。4.1 传统Servlet/JSP项目实战在没有框架加持的情况下我们需要手动构建防护层。防御XSS自定义过滤器与JSTL创建XSS防御过滤器虽然核心是输出编码但一个全局的请求参数过滤过滤器可以作为补充防线。WebFilter(/*) public class XSSFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { chain.doFilter(new XSSRequestWrapper((HttpServletRequest) request), response); } // XSSRequestWrapper 需要重写 getParameter, getParameterValues, getHeader 等方法 // 对获取到的字符串进行HTML转义。注意此方法可能误伤合法数据需谨慎设计过滤规则。 // 更推荐的做法是仅在此处进行简单的危险字符检查或日志记录核心防御放在输出端。 }强制使用JSTL进行输出在团队规范中明确所有JSP页面禁止使用% %脚本表达式输出动态内容一律使用c:out。设置响应安全头在过滤器中或单独的Filter里设置CSP和X-Content-Type-Options等头。httpResponse.setHeader(Content-Security-Policy, default-src self;); httpResponse.setHeader(X-Content-Type-Options, nosniff); // 禁止浏览器MIME嗅探 httpResponse.setHeader(X-Frame-Options, DENY); // 禁止页面被iframe嵌入防点击劫持防御CSRF手动实现Token机制生成Token工具类public class CSRFTokenUtil { private static final SecureRandom secureRandom new SecureRandom(); public static String generateToken() { byte[] bytes new byte[16]; secureRandom.nextBytes(bytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes); } public static void storeToken(HttpSession session, String tokenKey) { session.setAttribute(tokenKey, generateToken()); } public static String getToken(HttpSession session, String tokenKey) { return (String) session.getAttribute(tokenKey); } public static boolean isValid(HttpServletRequest req, String tokenKey) { String sessionToken getToken(req.getSession(false), tokenKey); String requestToken req.getParameter(tokenKey); return sessionToken ! null sessionToken.equals(requestToken); } }应用Token在展示表单的Servlet中生成Token并存入Session同时传递给JSP。CSRFTokenUtil.storeToken(request.getSession(), csrfToken); request.setAttribute(csrfToken, CSRFTokenUtil.getToken(request.getSession(), csrfToken));在JSP表单中添加隐藏域。input typehidden namecsrfToken value${csrfToken}在处理表单提交的Servlet中验证Token。if (!CSRFTokenUtil.isValid(request, csrfToken)) { throw new SecurityException(CSRF token validation failed.); } // 验证通过后可以移除或更新旧Token4.2 Spring Boot项目集成实践Spring Boot Spring Security让安全配置变得声明式和模块化。防御XSS依赖库与配置输入过滤在Controller层使用Valid注解配合JSR-303校验注解如NotBlank,Email。对于复杂过滤在Service层引入OWASP Java HTML Sanitizer。输出编码Thymeleaf模板Thymeleaf默认会对所有th:text进行HTML转义。对于需要输出原始HTML的情况使用th:utext要极其小心确保内容绝对安全。前后端分离后端API返回JSON数据前端负责渲染。这时XSS防御的责任主要转移到了前端。后端需要确保JSON中的字符串不包含未转义的HTML/JS。前端框架如React、Vue默认会对绑定到模板的数据进行转义。配置安全响应头在application.properties或通过配置类设置。# 示例设置CSP头 (通过Spring Security配置更佳) # security.headers.content-security-policydefault-src self防御CSRFSpring Security的自动化防护Spring Security默认启用CSRF防护。你需要了解的是如何与之协作。Thymeleaf表单使用th:action和Spring Security的标签库Token会自动添加。form th:action{/do-something} methodpost !-- Spring Security会自动在此处插入一个名为 _csrf 的隐藏input -- input typesubmit valueSubmit/ /formAjax请求需要手动获取Token并添加到请求头中。Spring Security通常将Token存放在meta标签或Cookie中。// 从meta标签获取 var token document.querySelector(meta[name_csrf]).getAttribute(content); var header document.querySelector(meta[name_csrf_header]).getAttribute(content); // 使用Fetch或Axios发送请求时设置请求头 fetch(/api/endpoint, { method: POST, headers: { Content-Type: application/json, [header]: token // 动态设置头名 }, body: JSON.stringify(data) });自定义与禁用如果需要自定义Token仓库或验证逻辑可以配置CsrfTokenRepository。对于纯无状态API可以考虑禁用CSRF。Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .csrf(csrf - csrf .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse()) // 将Token存在Cookie中供JS读取 // .ignoringRequestMatchers(/api/public/**) // 忽略某些路径 // .disable() // 谨慎禁用 ) // ... 其他配置 return http.build(); } }5. 进阶安全编码习惯、测试与漏洞挖掘防御措施是盾良好的编码习惯和主动测试则是打造盾牌的工艺。5.1 必须养成的安全编码习惯明确数据边界时刻清楚一段数据来自哪里不可信的用户输入、可信的内部系统、配置文件以及它要到哪里去HTML页面、SQL语句、操作系统命令、日志文件。针对不同的“去处”采取相应的编码或过滤。使用安全API优先使用提供自动转义或参数化功能的API。数据库永远使用PreparedStatement而不是字符串拼接SQL。执行命令避免Runtime.exec(String command)使用传递字符串数组的版本。文件路径使用PathAPI进行规范化防止路径遍历。最小化暴露Cookie设置HttpOnly和Secure属性。HttpOnly使Cookie无法被JavaScript访问能有效缓解XSS盗取Cookie的风险。Secure要求Cookie仅通过HTTPS传输。依赖安全管理定期使用OWASP Dependency-Check或Snyk等工具扫描项目依赖及时更新存在已知漏洞的第三方库。5.2 如何进行安全测试代码审计定期进行代码审查重点关注用户输入点HttpServletRequest.getParameter(),getHeader()、数据输出点JSP/Thymeleaf表达式、response.getWriter().print()、数据库操作、文件操作、命令执行等。黑盒测试手工测试使用浏览器开发者工具手动构造包含scriptalert(1)/script、img srcx onerroralert(1)、javascript:alert(1)等Payload的请求观察响应。工具扫描使用Burp Suite、OWASP ZAP等渗透测试工具进行自动化的漏洞扫描。它们可以爬取网站并自动尝试各种XSS和CSRF的Payload。CSRF测试手动创建一个简单的HTML页面包含一个指向你站点敏感接口的form或img标签在已登录目标站点的情况下打开这个HTML页面看请求是否会成功执行。或者使用Burp Suite的“生成CSRF PoC”功能。5.3 常见问题与排查实录问题1启用了Spring Security的CSRF防护后我的登录/注销POST请求被拒绝了。原因登录和注销表单也需要CSRF Token。Spring Security的默认登录/注销页面会自动处理。但如果你自定义了登录页面必须手动将Token放入表单。解决在自定义登录页面的表单中添加input typehidden th:name${_csrf.parameterName} th:value${_csrf.token} /。确保登录请求的URL也被包含在CSRF防护中默认是包含的。问题2我的API接收JSON格式的POST请求CSRF Token应该放在哪里原因CSRF Token传统上放在表单字段或请求头中。对于JSON请求无法放在请求体里因为Body已经是JSON格式。解决标准做法是将Token放在HTTP请求头中例如X-CSRF-TOKEN。前端需要在发起请求前从Cookie或Meta标签获取Token并设置到Header里。Spring Security的CookieCsrfTokenRepository策略就是为方便这种场景设计的。问题3使用了c:out但某些地方还是出现了XSS。排查检查是否错误地使用了c:out escapeXmlfalse这关闭了转义功能非常危险。检查输出点是否不在HTML正文而是在JavaScript代码块内、HTML标签的属性内尤其是href、src、onclick等事件属性。对于这些上下文c:out的HTML编码可能不够。检查是否是DOM型XSS。查看页面JavaScript代码是否有eval()、setTimeout()、innerHTML直接使用了来自URLlocation.hash或用户输入的数据。问题4CSP策略太严格导致我的页面样式或脚本加载失败。解决CSP策略应该采用逐步收紧的策略。首先设置一个仅报告而不拦截的策略头Content-Security-Policy-Report-Only并配置report-uri或report-to指令来收集违规报告。分析报告了解页面正常运行需要加载哪些资源。根据报告逐步完善和收紧CSP策略最后将-Report-Only后缀去掉正式启用拦截模式。安全是一个持续的过程而不是一个可以一劳永逸的开关。将上述防御措施融入到开发和部署流程中定期进行安全培训和代码审计才能构建起真正有韧性的Web应用。从我个人的经验来看最大的风险往往不是来自高深的技术漏洞而是源于开发者的疏忽和对“内部系统”、“小功能”的侥幸心理。每一次对用户输入的无条件信任都可能为攻击者打开一扇门。
