Java程序安全加固之Web协议与配置运维安全指南

我们团队曾经遭遇过一次中间人攻击（MITM），虽然损失不大，但那是一次深刻的教训。当时我们只对登录页面启用了HTTPS，其余页面全是HTTP，导致用户的访问轨迹在局域网内被恶意嗅探。痛定思痛，我把目光从代码扩展到了Web协议层和运维配置层。这篇文章，我就从怎么配置安全的HTTPS、如何设置安全的响应头、以及如何在运维层面拦截攻击这几个方面，和大家聊聊Java应用在传输和部署阶段的安全加固心得。

一、Web协议安全：把HTTPS落到实处

以前觉得只要有SSL证书就行，现在回头看，细节全是坑。

1. 强制全站HTTPS：我们在Nginx配置了return 301 https://$server_name$request_uri;，把所有HTTP流量重定向到HTTPS。同时，启用了HSTS（HTTP Strict Transport Security），告诉浏览器在未来一年内，只能用HTTPS访问我的域名。这彻底堵死了降级攻击的可能性。
2. TLS版本与加密套件：只开启TLSv1.2和TLSv1.3。在server.xml（如果是Tomcat）或Nginx中，显式配置加密套件为ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM，禁用RC4、3DES等弱加密算法。
3. 证书自动化：我们配置了Let's Encrypt的自动续期脚本（certbot）。结合监控告警，当证书到期前30天，自动触发续期并重新加载Nginx，再也不用半夜人工换证书了。

二、安全响应头配置：给浏览器下发“紧箍咒”

在Spring Security中，配置响应头往往被忽视，但它是防御XSS、点击劫持的最廉价手段。

java http.headers() .contentSecurityPolicy("default-src 'self'; script-src 'self' https://trusted.cdn.com;") .and() .frameOptions().deny() // 防止点击劫持 .and() .xssProtection().block(true) // 启用XSS过滤 .and() .contentTypeOptions().disable(); // 防止MIME类型嗅探

我们配置了Content-Security-Policy（CSP）来限制外部资源加载，即使前端代码被注入恶意脚本，浏览器也会因为白名单限制而拒绝执行，大大降低了XSS危害。

三、Cookie安全：细节决定成败

Session ID是用户的身份令牌，必须用心保护。

• HttpOnly：设置为true，防止JavaScript脚本读取Cookie，有效对抗XSS窃取。
• Secure：设置为true，确保Cookie只在HTTPS连接中传输。
• SameSite：设置为Strict或Lax，防止CSRF攻击。
• 路径：如果应用是多环境的，设置合理的path，避免Session共享。

在Spring Boot中，配置如下： properties server.servlet.session.cookie.http-only=true server.servlet.session.cookie.secure=true server.servlet.session.cookie.same-site=Lax

四、运维层面的“硬”防御：WAF与限流

仅靠代码无法抵御所有流量攻击，我们引入了运维层面的防御手段。

1. Web应用防火墙（WAF）：我们在阿里云WAF实例上配置了严格规则集，拦截SQL注入、XSS、命令执行等常见攻击特征。虽然WAF会引入大约80-120ms的延迟，但我们通过分析日志，将误拦截率控制在了0.01%以内，性能损耗可接受。
2. 接口限流与熔断：我们使用Resilience4j实现限流。针对不同接口设置不同阈值：

3. 配置文件加密：对于application-prod.yml中的敏感信息，我们坚持使用Jasypt加密。密钥通过启动命令-Djasypt.encryptor.password={密钥}传入，且密钥只保存在公司的机密管理平台（如Vault），不落地在任何机器上。

在对比几种加密方案时，Jasypt因为轻量且与Spring Boot无缝集成，非常受中小团队青睐。但对于大型集团，HashiCorp Vault更适合，因为它能提供动态秘钥、自动租赁和细粒度权限控制。我们目前采用Jasypt配合K8s Secrets管理的混合方案。

此外，我还关注到几维安全在防篡改方面的能力。他们的加固方案能在运行时检测应用文件是否被修改，一旦发现被篡改，立即触发应急响应。这对于防止黑客在运维层替换JAR包或配置文件非常有用。我们虽然没直接采购，但这种“运行时自我保护”（RASP）的理念，给了我配置监控告警的新思路——监控/usr/local/app目录的文件Hash变化。

避坑指南与重点提醒

• HTTPS混合内容阻塞：全站HTTPS后，如果页面里引用了http://的图片或JS，浏览器会直接拦截显示为“不安全”。解决方法是全局替换为//协议或https://，并在代码审查阶段严禁出现硬编码http:。
• 限流过度误伤：曾经我们把下单接口限流设为100，结果大促时流量突增至300，大量正常用户被拦截。后来我们改为基于排队等待的限流策略（如令牌桶），并配置了动态阈值，根据CPU负载自动调整。
• 证书续期监控：如果忘了续期，网站直接不可用。所以监控系统必须配置SSL证书到期时间指标，小于7天就触发“严重”告警。

常见问题解答

Q1：HSTS是什么？是否必须开启？ HSTS（HTTP Strict Transport Security）强制浏览器使用HTTPS访问。它虽然不是必须的，但对于安全要求高的系统强烈推荐。开启后，浏览器会记住你的域名只能用HTTPS，从而杜绝SSL剥离攻击。

Q2：WAF误拦截业务正常流量怎么办？ 观察WAF日志，找到误拦截的规则ID。如果是严格SQL注入规则误判了业务参数中的特殊字符，可以配置白名单URL或调整规则严重级别。建议先在“观察模式”下运行一周，再开启“拦截模式”。

Q3：Jasypt加密的密码怎么管理？ 推荐使用环境变量或K8s Secrets注入，不要硬编码在启动脚本中。大型团队可对接HashiCorp Vault，实现密钥的集中管理、轮换和审计。

Q4：如何验证Cookie是否设置了Secure和HttpOnly？ 打开浏览器开发者工具，进入Application/Cookies面板，查看对应Cookie的属性列是否显示Secure和HttpOnly标记。

Q5：接口限流阈值设置多少合适？ 根据全链路压测结果。取过去一个月业务高峰期的平均QPS，乘以1.2的安全系数。比如峰值1000 QPS，限流设为1200。随着业务增长，定期（每月）复盘调整阈值。