JSP网站前端XSS防范：企业容易忽视的编码细节

日期 : 2026-11-06 00:03:31

很多企业官网、后台系统和政务类站点至今仍跑在 JSP 技术栈上。这类服务端渲染的页面有一个共同特点：用户提交的数据、URL 参数和数据库记录，会被直接拼进 HTML 再返回浏览器。一旦某个变量没有经过正确转义，一段精心构造的脚本就会被执行——这就是 XSS（跨站脚本）攻击。它不像漏洞扫描器里的高危端口那样显眼，却能直接窃取 Cookie、冒充用户操作、篡改页面内容，是企业 Web 安全中复发率最高的一类问题。

01 为什么 JSP 老站容易成为 XSS 重灾区

XSS 的本质并不复杂：浏览器把"服务端返回的字符串"当成可执行脚本运行。JSP 之所以风险集中，原因有三点。

第一，服务端渲染让数据天然嵌入 HTML。与前后端分离后由前端框架自动转义不同，JSP 把 Java 变量、请求参数直接写在页面里，开发者稍不留神就会漏掉一处输出点。

第二，历史代码积累多。早期项目大量使用 <%= request.getParameter("kw") %> 这种裸表达式，既不校验也不转义，后续迭代很难逐页翻查。

第三，前端资源被信任。很多企业站点引入了第三方统计、客服、广告脚本，一旦任一入口被注入，攻击面就会成倍放大。

02 三类 XSS 在 JSP 中的具体样子

反射型：攻击者把恶意脚本藏在 URL 参数里，诱导用户点击后，服务器把参数原样回显在页面上。例如搜索结果页、错误提示页，最常见的就是 ?kw=<script>...</script> 被直接拼回 HTML。

存储型：危害更大。攻击者把脚本写进数据库（留言、评论、昵称、订单备注），其他用户浏览该页面时，服务器从库里读出恶意内容并渲染，脚本就在每个访问者的浏览器里执行。

DOM 型：脚本根本不经过服务端，而是前端 JS 读取 URL、LocalStorage 后直接写入页面。JSP 页面里大量内联 JS，只要出现 document.write(location.hash)、innerHTML = param 这类写法，就会中招。

03 高危写法：这些输出姿势正在埋雷

排查老项目时，下面几类代码几乎必然是漏洞点，建议作为代码评审的强制检查项。

裸 JSP 表达式：<%= request.getParameter("q") %> 不做任何编码，直接反射到页面。

EL 表达式默认不转义：JSP 2.0 之后，${param.q} 在输出到 HTML 时并不会自动转义，很多人误以为"用了 EL 就安全"，恰恰相反。

JSTL 关闭了转义：<c:out value="${name}" escapeXml="false"/> 为了保留富文本而关掉转义，是最常见的误操作。

JS 块里拼接 Java 变量：<script>var uName = "${user.name}";</script>。当昵称里包含引号或尖括号，就会提前闭合字符串，注入任意脚本。

04 四道防线：从编码到响应头

第一道，网站建设输出编码优先于输入过滤。不同上下文需要不同的编码：HTML 正文用 HtmlUtils.htmlEscape()，HTML 属性值要额外转义引号，JS 字符串上下文要用 JsonUtils 或 OWASP Java Encoder 输出为 JSON 字符串。能使用 <c:out> 就不要写裸表达式，并且保持 escapeXml="true"。

第二道，输入校验做白名单。昵称、手机号、邮箱、订单号这类字段，在服务端用正则或业务规则限定字符集；富文本场景不要靠"过滤 script 标签"，而应引入 OWASP Java HTML Sanitizer 做白名单净化。

第三道，用响应头缩小攻击面。在 Filter 中统一下发 Content-Security-Policy，限制脚本只能来自白名单域名；为会话 Cookie 设置 HttpOnly、Secure 和 SameSite，即使 XSS 成功也偷不到登录态。

第四道，前端写法收敛。JSP 页面里避免使用 document.write 写入用户数据；改用 textContent 或 setAttribute；确需渲染 HTML 时，先经过净化库。