Java老旧Web项目XSS漏洞的解决方案
作者：山顶听风
对于老旧项目，从服务器或中间件层面进行加固是一个非常务实且高效的短期解决方案。
这可以在不修改或极少修改代码的情况下，立即提升系统的安全水位。
方案一：部署Web应用防火墙（WAF）—— 最快速、最有效的临时方案
WAF是位于Web应用程序之前的防护屏障，通过检查所有流入的HTTP/HTTPS流量来识别和阻挡恶意攻击，包括XSS、SQL注入等。
如何实施：
云WAF（首选，最快部署）：
- 如果您的应用已经部署在云上（如阿里云、腾讯云、AWS），这些平台都提供托管的WAF服务。
- 操作：只需将您的域名CNAME解析到云WAF提供的地址上，流量就会先经过WAF的清洗再到达您的服务器。
- 优点：无需安装任何软件，分钟级上线，自带最新的攻击规则库，有图形化界面方便管理黑白名单和查看攻击日志。
软件WAF（如ModSecurity）：
- 如果服务器是自建的，可以在您的Web服务器（如Nginx、Apache）前部署一个反向代理服务器，
- 并安装开源的WAF软件，最著名的是 ModSecurity 及其规则集 OWASP Core Rule Set (CRS)。
以Nginx为例：
- 编译Nginx时加入
modsecurity模块。 - 下载OWASP CRS规则集。
- 在Nginx配置中启用ModSecurity并加载CRS规则，CRS规则中就包含专门检测XSS的规则。
- 优点：免费，高度可定制。
- 缺点：部署和配置有一定技术复杂度，需要自行维护规则更新。
WAF的优缺点：
- 优点：立即生效，防护全面（不止XSS），几乎无需修改应用代码。
- 缺点：可能存在误拦（需要调整规则）或绕过（但现代WAF规则库非常强大），是一种“缓解”措施而非“修复”措施。
方案二：配置严格的内容安全策略（CSP）响应头—— 现代浏览器的强力武器
CSP是一个HTTP响应头，它告诉浏览器只允许执行或加载来自哪些源的资源，从而极大地减少XSS成功后的危害。
如何实施：
在您的Web服务器（如Tomcat、Nginx、Apache）的配置中，或者在一个简单的Servlet Filter中，为所有响应添加Content-Security-Policy头。
示例（一个非常严格的策略）：
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none';
default-src 'self': 默认所有资源（脚本、图片、样式等）只能从当前域名加载。script-src 'self': 脚本只能从当前域名加载。这会禁止所有内联脚本（如<script>...</script>和onclick=...）执行，而XSS攻击往往依赖于内联脚本。object-src 'none': 完全禁止<object>,<embed>,<applet>等插件，这些也是攻击向量。
配置方法：
在Nginx中配置（推荐，在服务器层面统一管理）：
# 在server块中添加
server {
listen 80;
server_name yourdomain.com;
# 添加CSP头
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';" always;
location / {
proxy_pass http://your_tomcat_app;
}
}修改后重启Nginx：sudo nginx -s reload
在Tomcat的web.xml中配置（使用Filter）：
如果应用直接由Tomcat服务，可以写一个简单的Filter来添加响应头。
public class CSPFilter implements Filter {
@Override
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
response.setHeader("Content-Security-Policy", "default-src 'self'; script-src 'self'; object-src 'none';");
chain.doFilter(req, res);
}
// ... init和destroy方法
}然后在web.xml中配置这个Filter，映射到/*。
CSP的优缺点：
- 优点：极其有效，是现代防御XSS的标杆。即使攻击者成功注入了脚本，浏览器也不会执行它。
- 缺点：如果您的老应用大量使用了内联脚本和样式，启用严格的CSP会导致网站功能损坏。此时需要采用逐步实施策略：先只设置
Content-Security-Policy-Report-Only头，浏览器只会报告违规行为而不会阻止执行，您根据报告逐步调整策略，直到没有违规后再切换到强制模式。
方案三：配置其他安全相关的HTTP响应头
这些头可以进一步加固浏览器行为，作为辅助手段。
X-Content-Type-Options: nosniff
- 作用：阻止浏览器对响应内容类型进行嗅探（MIME-sniffing），强制浏览器使用
Content-Type头中定义的类型来渲染内容。可以防止将文本文件误当作JS执行。 - 配置（Nginx）：
add_header X-Content-Type-Options "nosniff" always;
X-Frame-Options: DENY 或 SAMEORIGIN
- 作用：禁止网站被嵌入到
<iframe>中，防止点击劫持（Clickjacking）攻击。 - 配置：
add_header X-Frame-Options "SAMEORIGIN" always; # 只允许同源网站iframe
HttpOnly 和 Secure Cookie 标志
作用：HttpOnly使Cookie无法通过JavaScript的document.cookie访问，有效缓解XSS攻击后的Cookie窃取。Secure要求Cookie只能通过HTTPS传输。
配置：这个通常需要在应用代码中设置，但如果是Tomcat，可以在context.xml中为所有Session Cookie全局配置：
<Cookie httpOnly="true" secure="true" /> <!-- 如果用了HTTPS，就设置secure="true" -->
总结与行动建议（服务器层面）
立即实施（第一天）：在Nginx/Apache配置中添加安全头，特别是 X-Content-Type-Options 和 X-Frame-Options。这几乎没有风险。
短期方案（第一周）：
- 首选：联系云厂商或安全团队，部署云WAF。这是最快、最专业的缓解措施。
- 次选：如果无法用云WAF，研究部署ModSecurity。
- 中期方案（并行进行）：配置CSP报告模式（
Content-Security-Policy-Report-Only）。分析报告，了解需要调整哪些策略才能兼容现有应用功能，为最终启用强制CSP做准备。
重要提示：
服务器配置是外部加固，相当于给老房子安装了防盗门和监控（WAF+CSP），极大地增加了攻击难度。但它不能修复房子本身结构上的漏洞（代码逻辑）。
从长远看，一旦有了时间，仍然应该推动实施输出编码这一根本解决方案。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。