wgpsec Java 前端安全类漏洞源码审计
本 skill 聚焦源码层面判断"前端安全漏洞是否成立"，核心是验证用户输入在输出到 HTTP 响应（HTML/Header/Cookie/重定向）过程中的过滤与转义是否充分。构造 payload、绕 WAF 等运行时利用技术属于对应黑盒 exploit skill 范畴。
深入参考
- 5 类前端漏洞的危险模式 / 安全模式代码对比 / EVID 证据示例 -> references/frontend-vuln-patterns.md
5 类前端安全漏洞速查表
| 类型 | 典型 Sink | 危险模式 | 严重度 |
|---|---|---|---|
| XSS | JSP <%= %>, th:utext, ${var?no_esc}, out.println() |
用户输入未经转义直接输出到 HTML/JS 上下文 | High-Medium |
| CSRF | 状态变更 POST/PUT/DELETE 接口 | csrf().disable() 或缺少 Token 校验的写操作端点 |
High-Medium |
| 开放重定向 | sendRedirect(), return "redirect:" + url |
用户可控 URL 直接传入重定向函数 | Medium |
| CRLF 注入 | setHeader(), addHeader(), addCookie() |
用户输入未过滤 \r\n 直接写入 HTTP 头 |
Medium-High |
| Session 管理 | getSession(), Cookie 构造, session-timeout |
登录后未重建 Session / Cookie 缺少安全属性 | Medium-High |
通用审计流程（4 步）
Step 1 -- 确认 EVID 证据点: 从 java-audit-pipeline Phase 3 产出的 EVID_* 证据中，筛选前端安全类条目（EVID_XSS_*、EVID_CSRF_*、EVID_REDIR_*、EVID_CRLF_*、EVID_SESSION_*）。没有 EVID 证据的 Sink 只能标"待验证"。
Step 2 -- 判断过滤有效性: 追踪 Source->Sink 路径上每一步过滤/转义操作，评估其对当前漏洞类型是否有效。常见陷阱: <c:out> 安全但 <%= %> 不转义、th:text 安全但 th:utext 不转义、URL 白名单可被 //evil.com 绕过。
Step 3 -- 评估绕过可能性: 过滤存在但不充分时，分析具体绕过路径（上下文切换、编码差异、URL 解析差异等）。能给出绕过思路则标"已确认"，否则标"待验证"并记录已知过滤方式。
Step 4 -- 确定严重度: 使用 java-audit-pipeline 的三维度评分公式 Score = R*0.40 + I*0.35 + C*0.25。XSS 存储型 I=2-3，反射型 I=1-2；CSRF 取决于被保护操作的影响。
XSS 审计要点
- JSP 输出:
<%= request.getParameter("x") %>和<% out.println(input); %>均不转义，直接输出到 HTML 即反射型 XSS；安全写法:<c:out value="${param.x}"/>或${fn:escapeXml(param.x)}，JSTL 默认转义 HTML 实体 - Thymeleaf:
th:utext="${userInput}"不转义（原始 HTML 输出）——危险；th:text="${userInput}"自动 HTML 转义——安全 - FreeMarker: 全局配置
output_format=HTMLOutputFormat+auto_escaping_policy=ENABLE_IF_SUPPORTED后默认转义；${var?no_esc}显式跳过转义——危险；未配置全局转义时所有${}均危险 - 上下文差异: HTML body 转义
< > & " '即可；HTML attribute 需额外处理引号闭合；JavaScript 上下文需 JS 编码而非 HTML 转义；URL 参数需 URL 编码——不同上下文使用错误的转义函数等于无防御 - DOM-based XSS: 后端返回 JSON 被前端
innerHTML/document.write()/eval()渲染，后端审计需确认 JSON 响应的Content-Type是否为application/json而非text/html - 存储型 XSS: 数据从数据库取出后未转义直接输出——追踪入库点是否做了过滤，出库点是否做了转义
- 富文本场景: 需使用白名单过滤库如 OWASP Java HTML Sanitizer (
PolicyFactory) 或Jsoup.clean(html, Safelist.basic())
CSRF 审计要点
- Spring Security 默认: CSRF Token 默认开启，但 REST API 项目常见
.csrf().disable()（旧版）或http.csrf(csrf -> csrf.disable())（Lambda DSL）——全局关闭后所有状态变更端点均暴露 - 自定义 Token: 评估生成强度（
SecureRandom安全 vsMath.random()可预测）、是否绑定 Session、校验时机（Controller 层 vs Filter 层） - Token 传递: 表单用
<input type="hidden" name="_csrf" value="..."/>；AJAX 用X-CSRF-TOKEN请求头配合<meta name="_csrf">读取——缺失任一传递方式则该场景无防护 - CORS 与 CSRF 的关系: 宽松 CORS（
Access-Control-Allow-Origin: *+Allow-Credentials: true）可被跨域 JS 读取响应中的 CSRF Token，间接绕过 CSRF 防护 - GET 请求状态变更: GET 执行写操作（如
/deleteUser?id=1）天然无 CSRF 防护——<img src="">即可触发
开放重定向审计要点
- Servlet 直接重定向:
response.sendRedirect(request.getParameter("url"))/response.sendRedirect(request.getParameter("next"))——用户完全可控 - Spring MVC:
return "redirect:" + target或RedirectView(url)中 target 来自请求参数 - 绕过手法:
//evil.com（协议相对 URL）、/\evil.com（部分解析器视\为路径分隔符）、URL 编码%2F%2Fevil.com、@符号http://trusted.com@evil.com、unicode 同形异义字 - 安全模式: 白名单域名校验 + 限制仅相对路径（以
/开头且不以//开头）；使用UriComponentsBuilder解析后校验 host
CRLF 注入审计要点
- HTTP Header 注入:
response.setHeader("X-Custom", userInput)或response.addHeader("Location", "/path?lang=" + input)——注入\r\nSet-Cookie: admin=1可设置任意头 - Servlet 容器差异: Tomcat 7.0.67+ / Jetty 9.2.15+ 默认拒绝 Header 值中的
\r\n；旧版本或自定义 HTTP 框架（如 Netty 原始 API）可能无此保护——确认容器版本是关键 - Cookie 值注入:
new Cookie("lang", userInput)——注入\r\nSet-Cookie: session=evil可劫持 Session - 安全模式: 过滤或拒绝值中的
\r、\n、\0控制字符；升级到较新版本 Servlet 容器
Session 管理审计要点
- Session 固定: 登录前后 Session ID 不变——攻击者诱导受害者使用已知 Session ID；安全模式: 登录成功后
request.getSession().invalidate()+request.getSession(true)重建；Spring SecuritySessionFixationProtection.migrateSession默认启用 - Cookie 属性:
HttpOnly防 XSS 窃取 Cookie（cookie.setHttpOnly(true)）；Secure限制仅 HTTPS 传输（cookie.setSecure(true)）；SameSite=Lax/Strict防 CSRF（Servlet 4.0+ 或 Springserver.servlet.session.cookie.same-site） - 超时配置:
web.xml中<session-timeout>30</session-timeout>（分钟）；Spring Bootserver.servlet.session.timeout=30m；过长超时增加 Session 劫持窗口 - 并发登录控制: Spring Security
sessionManagement().maximumSessions(1).maxSessionsPreventsLogin(true)——未配置时同一账户可多点登录，被盗凭据难以发现
检测清单
- 所有前端安全类 EVID_* 证据点已逐一审查
- JSP
<%= %>/out.println()输出点均已确认是否转义，Thymeleafth:utext已全部标记 - CSRF 保护状态已确认（是否 disable、Token 传递方式、GET 写操作）
- 重定向 Sink 的 URL 来源和白名单校验已确认
- HTTP Header/Cookie 写入点的用户输入过滤已检查，容器版本已记录
- Session 生命周期（固定/超时/并发/Cookie 属性）已审查
- 过滤不充分的点已给出具体绕过思路或标"待验证"
- 严重度评分使用了统一公式，与 pipeline 一致