Spring Boot + Shiro 等保三级复测实战：12行代码修复高危漏洞

1. 项目背景与核心挑战

最近，我们团队负责维护的一套基于Spring Boot和Shiro的医疗信息系统，迎来了等保三级（网络安全等级保护第三级）的年度复测。对于非技术出身的同事可能不太清楚，等保三级是国内非银行机构的最高安全认证等级，尤其在医疗行业，它直接关系到患者隐私数据的安全和系统的合规性。复测不通过，轻则限期整改、通报批评，重则可能影响医院的评级和业务开展。压力可想而知。

我们这套系统已经稳定运行了几年，上次定级测评是顺利通过的。本以为这次复测只是走个流程，但安全测评机构带来的扫描器和渗透测试手段比几年前“犀利”了不少。预检阶段，扫描报告就标红了好几处，其中指向Shiro框架的高危漏洞让我们心头一紧。Shiro作为一个强大且易用的Java安全框架，广泛应用在权限控制上，但它历史上爆出的反序列化漏洞（Shiro-550, Shiro-721等）堪称“核弹级”，攻击者利用它可以直接拿到服务器权限。测评老师明确指出，如果这些漏洞风险不消除，复测一票否决。

留给我们的时间只有6个小时。这不是从零开始开发，而是在一个庞大的、正在线上运行的系统里，进行精准的“外科手术式”漏洞修复，必须确保修改能立即生效且不影响任何正常业务功能。经过紧张的代码审计和策略调整，我们最终通过删除和修改12行关键代码，成功堵上了漏洞，系统最终以零高危漏洞的结果通过了复测。这篇文章，我就把这12行代码背后的故事、修复原理以及实战中的避坑经验，毫无保留地分享出来。

2. 等保三级复测对Shiro框架的核心要求解析

等保三级测评对应用安全的要求非常具体，主要依据《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019）。在应用安全层面，它重点关注身份鉴别、访问控制、安全审计、软件容错和资源控制等。落到我们使用的Spring Boot + Shiro组合上，测评老师会着重检查以下几点：

2.1 身份鉴别的强度与防爆破要求登录模块必须支持口令复杂度检查、失败处理机制（如连续错误锁定账户）和防止验证码绕过。Shiro本身不提供这些，需要我们在业务逻辑层或整合Spring Security时实现。但更关键的是，Shiro的RememberMe（记住我）功能，如果配置不当，就是最典型的身份鉴别绕过漏洞。

2.2 访问控制的粒度与有效性要求实现主体（用户）到客体（功能、数据）的访问控制。Shiro的注解（如@RequiresRoles,@RequiresPermissions）和标签库虽然好用，但测评会测试越权访问，例如普通用户是否能通过修改URL参数访问管理员接口。这要求我们的权限配置必须细致到每个URL或方法，并且后端校验必须坚实，不能仅依赖前端隐藏按钮。

2.3 会话管理的安全性这是Shiro的重灾区。等保要求会话令牌（Session ID）应具有不可预测性，并设置合理的超时时间。Shiro默认的SessionManager和用于RememberMe的Cookie其密钥（cipherKey）的生成与管理，直接关系到反序列化漏洞是否存在。测评工具会尝试使用公开的Shiro默认密钥（如kPH+bIxk5D2deZiIxcaaaA==）来加密伪造的RememberMeCookie，如果系统使用了弱密钥或默认密钥，攻击将直接成功。

2.4 安全审计的完整性要求对用户的重要操作（尤其是增删改和查看敏感数据）进行日志记录，并且日志不能被非授权删除或篡改。Shiro可以通过自定义Realm或监听器（如AuthenticationListener）来记录登录成功/失败事件，但这部分需要我们自己拓展。

我们接到的预检报告，红色高危项几乎全部集中在2.3 会话管理和由会话管理缺陷衍生出的2.1 身份鉴别绕过上。问题根源，就藏在Shiro那几行看似不起眼的配置代码里。

3. 高危代码定位：我们发现的12行“问题代码”

经过对代码库的紧急审计，我们定位到了三个关键文件中的12行代码。为了清晰，我先列出它们的位置和内容，后面再逐一详解修复方案。

3.1 第一处：Shiro配置类中的“罪恶之源”（5行）文件：ShiroConfig.java

@Bean public SecurityManager securityManager(DefaultWebSessionManager sessionManager){ DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager(); securityManager.setRealm(myRealm); // 问题代码行1-2：使用了默认的SessionManager且未配置全局会话超时 securityManager.setSessionManager(sessionManager); // sessionManager未经过安全配置 // 问题代码行3：启用RememberMe并使用了硬编码的弱密钥 CookieRememberMeManager rememberMeManager = new CookieRememberMeManager(); rememberMeManager.setCipherKey(Base64.decode("4AvVhmFLUs0KTA3Kprsdag==")); // 一个简单的硬编码密钥 securityManager.setRememberMeManager(rememberMeManager); return securityManager; } @Bean public DefaultWebSessionManager sessionManager(){ DefaultWebSessionManager sessionManager = new DefaultWebSessionManager(); // 问题代码行4-5：Cookie的SessionId生成器存在风险，且未设置HttpOnly/Secure属性 sessionManager.setSessionIdCookie(simpleCookie()); // simpleCookie配置不安全 return sessionManager; }

3.2 第二处：不安全的Cookie配置（4行）文件：ShiroConfig.java(接上)

@Bean public SimpleCookie simpleCookie(){ SimpleCookie cookie = new SimpleCookie("JSESSIONID"); cookie.setHttpOnly(false); // 问题代码行6：未启用HttpOnly，JS脚本可访问 cookie.setSecure(false); // 问题代码行7：未启用Secure，非HTTPS下也传输 cookie.setMaxAge(-1); // 问题代码行8：浏览器会话关闭即过期，但未考虑RememberMe场景的协调 // 问题代码行9：未显式设置SameSite属性，可能导致CSRF风险 return cookie; }

3.3 第三处：登录控制器中的“画蛇添足”（3行）文件：LoginController.java

@PostMapping("/login") public String login(User user, HttpServletRequest request) { Subject subject = SecurityUtils.getSubject(); UsernamePasswordToken token = new UsernamePasswordToken(user.getUsername(), user.getPassword()); try { subject.login(token); // 问题代码行10-12：登录成功后，强制更换SessionId的旧方案 HttpSession session = request.getSession(); session.invalidate(); // 销毁旧session request.getSession(true); // 创建新session，意图“防止固定会话攻击” return "redirect:/index"; } catch (AuthenticationException e) { return "login"; } }

这12行代码，每一行都代表着一个具体的安全隐患，共同构成了被测评工具识别出的高危漏洞。下面，我来详细拆解为什么它们是危险的，以及我们是如何修复的。

4. 逐行拆解与修复：从“高危”到“合规”

4.1 修复SessionManager与会话超时（对应问题行1-2, 4-5）

• 原代码风险：DefaultWebSessionManager在没有显式配置globalSessionTimeout的情况下，会使用默认值。更关键的是，通过simpleCookie()方法设置的Cookie不安全（下文详述）。此外，Shiro的SessionId生成器在旧版本可能存在熵不足（随机性不够）的问题。
• 修复方案：我们创建了一个加强版的SessionManagerBean，并显式配置了会话超时和安全的Cookie。

@Bean public DefaultWebSessionManager sessionManager(){ DefaultWebSessionManager sessionManager = new DefaultWebSessionManager(); // 修复1：设置全局会话超时时间为30分钟（1800000毫秒），符合等保对会话超时的要求 sessionManager.setGlobalSessionTimeout(1800000L); // 修复2：禁用URL重写携带SessionId，防止SessionId泄露在URL中 sessionManager.setSessionIdUrlRewritingEnabled(false); // 使用安全配置的Cookie sessionManager.setSessionIdCookie(sessionIdCookie()); return sessionManager; } @Bean public SimpleCookie sessionIdCookie(){ SimpleCookie cookie = new SimpleCookie("JSESSIONID"); cookie.setHttpOnly(true); // 关键修复：阻止JavaScript访问，防XSS盗取Session cookie.setSecure(true); // 关键修复：仅在HTTPS下传输，我们生产环境已全站HTTPS cookie.setMaxAge(-1); // 浏览器会话生命周期 // 关键修复：设置SameSite为Strict，严格防止CSRF（需浏览器支持） // 注意：Shiro的SimpleCookie未直接提供SameSite设置，需通过扩展或Servlet容器配置实现。 // 我们通过在应用的`application.yml`中统一配置了Tomcat的Cookie处理器来实现： // server: // servlet: // session: // cookie: // same-site: strict return cookie; }

实操心得：Secure=true的前提是你的网站确实启用了HTTPS，否则会导致Cookie无法传递，用户无法登录。SameSite属性是现代浏览器防御CSRF的重要机制，Strict模式最安全，但可能导致从第三方网站跳转回来时登录状态丢失。对于医疗系统，内部使用为主，我们采用了Strict。如果你的系统有大量外链跳转需求，可以考虑Lax模式。

4.2 重构RememberMe管理器，根治反序列化漏洞（对应问题行3）

• 原代码风险：使用硬编码的、强度不足的对称密钥（cipherKey）。这是Shiro反序列化漏洞的命门。攻击者如果知道了这个密钥，就可以伪造任意的RememberMeCookie，触发Shiro的反序列化逻辑，执行恶意代码。
• 修复方案：彻底加强密钥，并考虑业务场景决定是否保留该功能。
  • 方案A（推荐，我们采用的）：彻底禁用RememberMe功能。经与业务部门确认，医疗系统通常在院内固定终端使用，无需“记住我”功能。这是最彻底的安全方案。

  // 在securityManager的配置中，直接不设置RememberMeManager // securityManager.setRememberMeManager(null); // 或者直接注释掉这行配置

  • 方案B：如果业务必需，则使用高强度随机密钥。

  @Bean public CookieRememberMeManager rememberMeManager(){ CookieRememberMeManager manager = new CookieRememberMeManager(); // 关键修复：使用强随机生成的AES密钥，并Base64编码后存储 // 密钥长度必须是16字节（128位）、24字节（192位）或32字节（256位） KeyGenerator keyGen = KeyGenerator.getInstance("AES"); keyGen.init(256); // 使用256位AES byte[] cipherKey = keyGen.generateKey().getEncoded(); // 将生成的密钥Base64后，存入环境变量或配置中心，绝对不要硬编码在代码里！ String secureCipherKey = Base64.encodeToString(cipherKey); manager.setCipherKey(Base64.decode(secureCipherKey)); // 额外加固：设置RememberMe Cookie的生存期为7天，并同样启用HttpOnly和Secure SimpleCookie rememberMeCookie = new SimpleCookie("rememberMe"); rememberMeCookie.setHttpOnly(true); rememberMeCookie.setSecure(true); rememberMeCookie.setMaxAge(604800); // 7天 manager.setCookie(rememberMeCookie); return manager; }

踩坑警告：千万不要在网上搜索“Shiro默认密钥”或使用任何常见的测试密钥。测评机构的漏洞库包含了所有这些已知密钥。方案B中，密钥的生成和存储必须自动化、保密化。可以考虑在应用启动时，如果发现未配置密钥，则生成一个并写入安全的配置存储，同时告警通知管理员。

4.3 移除登录后强制刷新SessionId的冗余代码（对应问题行10-12）

• 原代码风险：这段代码的本意是防御“会话固定攻击”（Session Fixation）。即攻击者先获取一个SessionId，诱骗用户用这个Id登录，从而劫持用户会话。但session.invalidate()后立即getSession(true)，在并发场景下可能存在极短时间窗口的会话状态不一致问题，且Shiro在subject.login()成功时，已经自动创建了新的Session。这段代码是多余的，甚至可能引发异常。
• 修复方案：直接删除这三行代码。Shiro内部已经妥善处理了登录前后的会话变更。

// 正确的登录控制器核心代码 @PostMapping("/login") public String login(User user, HttpServletRequest request) { Subject subject = SecurityUtils.getSubject(); UsernamePasswordToken token = new UsernamePasswordToken(user.getUsername(), user.getPassword()); try { subject.login(token); // Shiro认证成功会自动关联新的安全Session // 删除旧的 session.invalidate() 和 request.getSession(true) 操作 return "redirect:/index"; } catch (AuthenticationException e) { // 记录登录失败日志，用于等保审计和账户锁定策略 log.warn("用户登录失败: {}", user.getUsername()); return "login"; } }

深度解析：Shiro的Subject.login()过程，其内部DefaultSecurityManager会调用createSubject方法构建一个新的Subject实例，并关联一个全新的Session。旧Session（如果是未认证的）会被废弃。因此，手动刷新是画蛇添足。防御会话固定攻击，更可靠的方法是在容器层面（如Tomcat）配置<session-config>中的tracking-mode为COOKIE，并确保我们的sessionIdCookie启用了Secure和HttpOnly。

5. 超越这12行：等保三级复测的额外加固点

通过修复上述12行代码，我们解决了最致命的高危漏洞。但要稳健通过等保，还需要在以下几个方面进行加固，这些也是测评老师会关注的地方：

5.1 密码传输与存储

• 传输：确保登录接口使用HTTPS（TLS 1.2+）。我们检查了Nginx配置，禁用了不安全的SSL协议和加密套件。
• 存储：在自定义的Realm中，我们验证了密码比对使用的是Shiro的HashedCredentialsMatcher，并且采用了SHA-256加盐散列，符合等保对密码存储的要求。

@Bean public HashedCredentialsMatcher hashedCredentialsMatcher(){ HashedCredentialsMatcher matcher = new HashedCredentialsMatcher(); matcher.setHashAlgorithmName("SHA-256"); matcher.setHashIterations(1024); // 迭代次数增加计算成本 matcher.setStoredCredentialsHexEncoded(true); return matcher; }

5.2 细粒度的权限注解与校验我们检查了所有控制器（Controller）的方法，确保敏感操作（如/patient/delete,/report/download）都添加了Shiro的权限注解@RequiresPermissions("patient:delete")或角色注解@RequiresRoles("admin")。并且，在服务层（Service）进行了二次校验，防止因配置错误导致越权。

5.3 关键操作审计日志在Shiro的AuthenticatingRealm的doGetAuthenticationInfo方法（登录认证）和自定义的授权部分，我们增加了详细的日志记录，记录用户登录成功/失败、权限变更等关键事件，日志统一输出到安全的日志服务器，并设置了严格的访问权限，满足等保审计要求。

5.4 依赖组件版本管理我们快速检查了pom.xml，确保使用的shiro-spring-boot-starter版本是最新的稳定版（当时是1.11.0），远离了已知的严重漏洞版本。同时，Spring Boot本身及其它组件（如Fastjson、Jackson）也更新到了无已知高危漏洞的版本。

6. 复盘总结：6小时应急响应的经验与教训

这次惊险的6小时等保复测应急，给我们团队上了深刻的一课。技术层面的修复固然重要，但流程和意识上的收获更值得分享：

6.1 安全需要“左移”，不能依赖最后的渗透测试这12行高危代码并非最近引入，它们可能从项目初期就存在了。这意味着我们的开发流程中缺少了持续的安全代码审查（Code Review）环节。现在，我们已经将Shiro安全配置、密码存储方式、Cookie属性设置等加入了团队的《编码安全规范》Checklist，并在每次代码合并请求（Merge Request）中强制审查。

6.2 默认配置即“危险配置”无论是Shiro的默认密钥，还是Tomcat的Session Cookie默认不启用HttpOnly，都告诉我们一个道理：框架和中间件的“开箱即用”配置往往以功能实现和兼容性为首要目标，安全性需要开发者主动去加固。永远不要使用默认的安全相关参数。

6.3 漏洞修复前，务必评估业务影响例如，在决定是否禁用RememberMe时，我们第一时间联系了业务负责人确认使用场景。盲目修复可能会阻断合法业务。再比如，设置Cookie Secure=true的前提是全站HTTPS，否则就是制造故障。

6.4 工具辅助，但理解原理是关键漏洞扫描器能快速指出问题，但它不会告诉你为什么以及如何最优雅地修复。只有深入理解Shiro的认证、授权、会话管理流程，理解反序列化漏洞的原理，才能做出像“删除冗余Session刷新代码”这样精准的修复，而不是盲目地打补丁。

最终，我们的系统在删改那关键的12行代码，并完成一系列加固后，重新部署上线。在后续的正式复测中，原先的高危漏洞全部清零，顺利通过了等保三级复测。这件事也让我们意识到，对于医疗、金融这类强监管行业的系统，安全不是一个功能，而是融入在每一行代码、每一个配置中的基础属性。