1. 项目概述一次对Shiro授权机制的深度剖析最近在复盘一些历史漏洞案例时我又仔细研究了一下CVE-2022-32532。这个漏洞虽然不像Shiro那些经典的反序列化漏洞比如Shiro-550、Shiro-721那样广为人知但它揭示的问题却非常典型——在复杂的权限校验逻辑中一个看似不起眼的路径处理差异就可能导致整个授权防线被轻易绕过。简单来说这是一个存在于Apache Shiro 1.9.0之前版本中的授权绕过漏洞攻击者可以通过构造特殊的请求路径让Shiro的权限校验机制“失明”从而访问到本应受保护的后台接口或资源。对于从事应用安全开发、渗透测试或者运维的朋友来说理解这类漏洞的成因远比单纯使用一个漏洞利用工具比如网上流传的各种Shiro反序列化漏洞利用工具更有价值。它能帮助我们从根本上审视自己项目中的权限设计是否严谨避免犯下类似的错误。这个漏洞的核心并不涉及复杂的加密或反序列化过程而是聚焦于Shiro框架对请求路径进行标准化Canonicalization处理时与后端Web容器如Tomcat、Spring MVC处理方式不一致所导致的“认知偏差”。当Shiro认为这个请求路径不该被放行时Tomcat可能已经将它成功路由到了对应的Controller方法上。接下来我会带你一起拆解这个漏洞的完整链条。我们会从Shiro的权限拦截原理讲起一步步分析路径标准化过程中出现的“分歧点”并亲手搭建环境进行复现。更重要的是我会分享在实际代码审计和防护中如何发现和规避这类路径标准化导致的权限校验漏洞。无论你是想深入理解Shiro安全机制还是希望加固自己的Web应用这篇文章都会提供直接的参考。2. 漏洞原理与授权机制深度解析要理解CVE-2022-32532我们必须先搞清楚Shiro是如何进行权限拦截的。这不仅仅是知道怎么配shiro.ini或者RequiresPermissions注解那么简单而是要深入到请求被处理的那一刻看看Shiro到底做了什么。2.1 Shiro权限拦截的核心流程Shiro通过一个名为ShiroFilter的Servlet Filter集成到Web应用中。每一个到达应用的HTTP请求都会先经过这个过滤器。它的核心工作流程可以概括为以下几个步骤接收请求获取原始的HttpServletRequest对象其中包含了用户请求的完整信息如URI、参数、方法等。路径匹配Shiro会根据配置文件中定义的一系列FilterChain规则来判断当前请求的路径应该由哪个或哪组过滤器来处理。这些规则通常使用Ant风格的路径匹配符比如/admin/** authc, roles[admin]。执行过滤链如果路径匹配成功则依次执行该链上定义的过滤器如authc认证过滤器、perms权限过滤器等。任何一个过滤器拒绝请求都会中断后续处理通常导向登录页或错误页。路径标准化关键步骤在进行路径匹配之前Shiro会对请求的URI进行一次“标准化”Canonicalization处理。这是本漏洞的关键所在。标准化的目的是为了消除URI中的歧义比如处理./、../、多余的/等防止路径遍历攻击并确保匹配的准确性。问题就出在这个“标准化”的逻辑上。Shiro有一套自己的标准化算法而Web容器如Tomcat、Jetty在将请求最终映射到Servlet或Controller时也有自己的一套路径解析和规范化逻辑。当这两套逻辑对同一个“畸形”路径的理解不一致时漏洞就产生了。2.2 路径标准化不一致的根源我们来看一个具体的例子。假设我们有一个受保护的接口其访问路径是/admin/list。在Shiro的配置中我们可能这样写/admin/** authc, roles[admin]。现在攻击者构造了这样一个请求GET /admin/%3b..%2flist HTTP/1.1。这里的%3b和%2f是URL编码分别对应分号;和斜杠/。所以这个请求的原始路径可以看作是/admin/;../list。Shiro的视角漏洞版本1.9.0Shiro收到请求获取到request.getRequestURI()假设得到/contextPath/admin/%3b..%2flist。Shiro开始进行标准化。在旧版本的WebUtilsgetPathWithinApplication方法或PathMatchingFilter的路径获取逻辑中对于URL解码和路径规范化的顺序或细节处理可能存在瑕疵。在某些处理流程中;分号在J2EE规范中常用于分割路径和参数如/path;jsessionidxxxShiro的标准化过程可能会将/admin/;../list中的;及其之后的部分进行特殊处理或截断导致标准化后的结果可能变成了/admin或者仍然包含特殊序列而未能正确回溯..。标准化后的路径例如/admin再去匹配过滤器链。它匹配到了/admin/**这条规则因此Shiro会要求用户具备admin角色。如果用户未登录或不具备admin角色Shiro过滤器链将拒绝此请求返回403或跳转登录。TomcatSpring MVC的视角Tomcat接收到同样的请求。Tomcat或Spring MVC的DispatcherServlet也有自己的请求路径解析逻辑。它对路径的规范化处理可能与Shiro不同。关键点在于Tomcat在处理/admin/;../list时可能会将;..进行解析。在某些版本或配置下Tomcat可能会将;视为路径参数的分隔符并在进行路径规范化时将;..及其之前的部分/admin/;作为一个“可忽略”的路径参数节点或者以某种方式使得..回退到了上一级。最终Tomcat成功将请求映射到了/list这个Servlet或Controller上。但更常见且危险的情况是经过Tomcat的URL解码和规范化后路径可能直接变成了/admin/list。于是一个被Shiro“拒绝”的请求被Tomcat“接受”并路由到了真正的业务接口/admin/list。授权绕过就此发生。核心矛盾Shiro认为请求是访问/admin或一个被其规则拦截的路径而Web容器最终将请求路由到了/admin/list。权限校验和请求路由的目标出现了偏差校验形同虚设。2.3 CVE-2022-32532的具体触发点根据漏洞公告和补丁分析CVE-2022-32532的触发与分号;的处理紧密相关。在Shiro 1.9.0之前的版本中org.apache.shiro.web.util.WebUtils#getPathWithinApplication方法或其相关路径处理逻辑在特定序列下例如包含;和..的组合未能正确地、与后端容器保持一致地完成路径的规范化导致攻击者可以构造包含URL编码的分号(%3b)和目录回溯(..)的序列来绕过路径匹配。补丁的核心思想是改进路径标准化算法确保Shiro处理后的路径与Web容器最终用于路由的路径保持一致消除歧义空间。通常做法是引入更严格、更符合Servlet规范的规范化逻辑或者对;等特殊字符进行更早、更统一的处理。3. 漏洞环境搭建与复现实操理解了原理我们动手搭建一个简易的漏洞环境来亲眼看看它是如何被触发的。这里我使用Spring Boot Shiro 1.8.0来模拟漏洞场景。3.1 环境准备与项目搭建首先我们创建一个简单的Spring Boot应用。1. 依赖配置 (pom.xml):dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 引入存在漏洞的Shiro版本 -- dependency groupIdorg.apache.shiro/groupId artifactIdshiro-spring-boot-web-starter/artifactId version1.8.0/version !-- 关键使用1.9.0之前的版本 -- /dependency /dependencies2. Shiro安全配置 (ShiroConfig.java):Configuration public class ShiroConfig { Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(DefaultWebSecurityManager securityManager) { ShiroFilterFactoryBean factoryBean new ShiroFilterFactoryBean(); factoryBean.setSecurityManager(securityManager); factoryBean.setLoginUrl(/login); factoryBean.setUnauthorizedUrl(/unauth); // 定义权限规则 MapString, String filterChainDefinitionMap new LinkedHashMap(); // 公开接口 filterChainDefinitionMap.put(/login, anon); filterChainDefinitionMap.put(/public/**, anon); // 管理员接口需要admin角色 filterChainDefinitionMap.put(/admin/**, authc, roles[admin]); // 关键配置 // 其他所有请求需要认证 filterChainDefinitionMap.put(/**, authc); factoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap); return factoryBean; } // 配置SecurityManager、Realm等为简化此处使用最简单的IniRealm Bean public DefaultWebSecurityManager securityManager() { DefaultWebSecurityManager securityManager new DefaultWebSecurityManager(); securityManager.setRealm(simpleAccountRealm()); return securityManager; } Bean public Realm simpleAccountRealm() { IniRealm realm new IniRealm(classpath:shiro-users.ini); return realm; } }3. 用户配置 (shiro-users.ini):[users] # 用户admin密码admin123拥有admin角色 admin admin123, admin # 普通用户user无admin角色 user user123, user4. 控制器代码 (TestController.java):RestController public class TestController { // 公开接口 GetMapping(/public/hello) public String publicHello() { return This is a public API.; } // 需要admin角色的管理接口 GetMapping(/admin/list) public String adminList() { return Admin List Data (Sensitive!); } // 登录页面模拟 GetMapping(/login) public String login() { return Please login.; } GetMapping(/unauth) public String unauth() { return Unauthorized!; } }环境搭建完毕。现在应用有一个受保护的接口/admin/list访问它需要用户登录且具备admin角色。3.2 漏洞复现过程我们启动应用然后使用curl或浏览器插件如Postman进行测试。步骤1正常访问测试未登录访问/admin/list会被Shiro重定向到/login。符合预期。使用普通用户user登录后访问/admin/list会返回Unauthorized!因为user角色不是admin。符合预期。使用管理员admin登录后访问/admin/list成功返回Admin List Data (Sensitive!)。符合预期。步骤2构造绕过Payload进行测试现在我们以未登录或者**普通用户user**的身份尝试构造漏洞Payload进行访问。假设应用部署在http://localhost:8080。Payload 1 (使用分号与回溯):curl -v http://localhost:8080/admin/%3b..%2flist%3b-;%2f-/实际路径/admin/;../listPayload 2 (变体):curl -v http://localhost:8080/admin/%3b/list实际路径/admin/;/listPayload 3 (另一种编码和组合):curl -v http://localhost:8080/admin/%3b%2e%2e/list%2e-.实际路径/admin/;../list(与Payload1等价)在Shiro 1.8.0环境下使用上述Payload之一具体哪个有效可能与环境细微差别有关通常需要测试你可能会观察到以下情况响应状态码可能是200而不是302重定向到登录页或403。响应体可能直接包含了Admin List Data (Sensitive!)。这就意味着Shiro的权限校验没有生效请求绕过了/admin/**的过滤器链直接被Spring MVC的DispatcherServlet路由到了TestController.adminList()方法并执行。实操心得在实际测试中Payload的成功率可能与具体的Spring Boot、Tomcat版本以及Shiro的配置方式有关。有时需要尝试多种;、..、/的URL编码组合和位置排列。这也是黑盒测试此类漏洞时常用“模糊测试”或“爬虫Payload替换”方式的原因。3.3 漏洞修复验证将项目中的Shiro依赖版本升级到1.9.0或更高。version1.9.0/version !-- 或更新版本 --重新启动应用再次使用相同的Payload进行测试。此时请求应该会被Shiro正确拦截返回登录页面或未授权提示证明漏洞已修复。4. 漏洞挖掘与代码审计视角从防御和代码审计的角度我们不仅要会复现更要学会如何发现这类问题。这不仅仅适用于Shiro也适用于任何自定义的权限拦截过滤器或网关。4.1 审计关键代码点当审计一个使用Shiro或其他权限框架的项目时应重点关注以下位置shiro.ini或ShiroFilterFactoryBean配置检查URL模式与控制器路径的对应关系是否清晰是否有过于宽泛的匹配如/**放行过早。自定义Filter如果项目继承了Shiro的PathMatchingFilter或AccessControlFilter需要仔细审查其isAccessAllowed或onAccessDenied方法中获取请求路径的逻辑。是否直接使用了request.getRequestURI()是否经过了正确的标准化处理WebUtils#getPathWithinApplication的调用点这是Shiro中获取应用内路径的核心方法。在旧版本中这里就是风险点。审计时看项目是否使用了存在漏洞的Shiro版本。权限注解与拦截器检查RequiresPermissions、RequiresRoles等注解的使用确保它们被正确地织入到了执行链中。但CVE-2022-32532这类路径绕过通常发生在Filter链层面注解层面可能无法防御。4.2 构造测试用例的思路在黑白盒测试中可以系统性地测试路径标准化差异特殊字符插入在受保护的路径中插入各种特殊字符观察响应差异。分号;:/admin/;/list,/admin/%3b/list冒号:(较少见):/admin/:/list反斜杠\(Windows路径特性在Web中常被规范化):/admin\list(可能被转为/admin/list)URL编码的斜杠%2f(/),%5c(\)多重编码%253b(对%3b再次编码即;的双重编码)路径遍历序列结合特殊字符使用..进行回溯。/admin/..;/list/admin/%2e%2e/list/admin/;../list/admin/..%2flist后缀/参数混淆尝试在路径后添加后缀或参数干扰匹配。/admin/list.js(如果配置是/admin/**可能仍匹配)/admin/list;jsessionidxxx/admin/list?x../(注意Shiro默认的getPathWithinApplication会去掉查询参数但自定义Filter可能处理不当)大小写混淆对于大小写敏感/不敏感的服务端或配置尝试/ADMIN/list、/Admin/list等。空格与特殊空白符%20,%00(空字节需谨慎可能引发其他问题)%0d,%0a等。注意事项在生产环境进行此类测试必须获得明确授权并在隔离的测试环境进行。一些畸形的Payload可能导致应用异常甚至崩溃。4.3 自动化探测脚本思路可以编写简单的脚本辅助探测import requests base_url http://target.com protected_path /admin/list # 已知受保护路径 proxies {http: http://127.0.0.1:8080} # 可选配合Burp观察流量 # 常见绕过Payload列表 payloads [ /admin/;/list, /admin/%3b/list, /admin/..;/list, /admin/%2e%2e/list, /admin/;../list, /admin/..%2flist, /admin/list/.., # 尝试访问 /admin /admin//list, # 双斜杠 /admin/./list, # ... 可以扩展更多 ] for payload in payloads: url base_url payload try: resp requests.get(url, proxiesproxies, timeout5, allow_redirectsFalse) # 判断逻辑如果访问受保护路径返回非重定向(302)且非错误(4xx,5xx)特别是返回了200和预期内容则可能绕过 if resp.status_code 200 and Sensitive Data in resp.text: # 替换为预期关键词 print(f[!] Possible Bypass: {url} - Status: {resp.status_code}) elif resp.status_code not in [302, 401, 403, 404]: print(f[?] Suspicious: {url} - Status: {resp.status_code}) except Exception as e: print(f[E] Error testing {url}: {e})这个脚本只是一个基础示例实际应用中需要更精细的状态码、响应头、响应体内容判断并考虑会话管理。5. 修复方案与安全加固实践对于CVE-2022-32532最直接有效的修复方案是升级Shiro。但升级框架只是基础更重要的是建立纵深防御体系避免“把鸡蛋放在一个篮子里”。5.1 官方修复方案升级Shiro立即行动将Apache Shiro升级至1.9.0或更高版本。这是修复该特定CVE的最根本方法。官方在1.9.0版本中重写了路径标准化相关的逻辑使其与Servlet容器的行为保持一致。升级检查清单版本确认检查所有项目的pom.xml或build.gradle确保Shiro依赖版本≥1.9.0。兼容性测试升级后必须进行全面的功能测试和回归测试。重点测试所有涉及URL权限控制的接口确保原有正常的权限校验依然有效没有因为路径处理逻辑改变而误拦截合法请求。依赖传递检查是否通过其他依赖如某个Spring Boot Starter间接引入了旧版本的Shiro确保依赖树中最终使用的是安全版本。5.2 应用层加固多重校验与安全编码不要完全依赖Shiro这一道防线。在应用层面增加校验可以极大提高攻击门槛。1. 在Controller方法入口进行二次校验这是非常有效的一招。即使请求绕过了Filter链只要它最终能调用到你的Controller方法你就有机会在方法开始处进行补救。RestController RequestMapping(/admin) public class AdminController { GetMapping(/list) public ResponseEntity? getAdminList(Principal principal) { // 注入Principal或从Session获取 // 二次权限校验 if (principal null || !hasAdminRole(principal.getName())) { // 直接返回403不执行业务逻辑 return ResponseEntity.status(HttpStatus.FORBIDDEN).body(Access Denied); } // 业务逻辑... return ResponseEntity.ok(sensitiveData); } private boolean hasAdminRole(String username) { // 实现你的角色校验逻辑可以查询数据库或缓存 // 注意这里应避免再次依赖可能存在问题的Shiro API建议使用应用自身的用户-角色关系数据 return userRoleService.hasRole(username, admin); } }2. 使用Spring Security作为互补在Spring生态中可以考虑同时使用Spring Security和Shiro虽然不常见或者直接迁移到Spring Security。Spring Security的过滤器链和路径匹配机制与Spring MVC整合更紧密但同样需要关注其自身的路径标准化安全问题。更常见的做法是在网关层如Spring Cloud Gateway, Zuul或API网关如Kong, APISIX进行统一的认证和粗粒度授权在业务服务内使用Spring Security或自定义注解进行细粒度授权。3. 严格规范URL设计避免模糊匹配尽量使用精确路径匹配减少使用/**、/*等通配符。如果必须使用将其放在过滤器链的最底部。清晰的目录结构将API接口按照功能模块划分到清晰的路径下如/api/v1/admin/xxx/api/v1/user/xxx。这样在配置权限时更直观也便于监控和审计。拒绝异常路径在全局过滤器或拦截器中可以对请求URI进行初步清洗拒绝包含连续斜杠(//)、URL编码的斜杠(%2f,%5c)、分号(;)等可疑字符的请求除非业务明确需要。但这种方法要谨慎避免误杀合法请求例如某些API可能允许分号作为参数分隔符。5.3 架构层防御纵深防御体系WAFWeb应用防火墙在应用前端部署WAF可以配置规则拦截包含..、;、%00等可疑路径遍历或编码特征的请求。这是应对已知漏洞攻击模式的有效缓解措施。API网关统一鉴权将所有流量先经过API网关。在网关层完成统一的身份认证如JWT校验和基础路由鉴权。这样即使后端某个服务的权限校验存在漏洞攻击者也必须先突破网关层的防线。定期安全扫描与代码审计将类似“路径标准化绕过”作为代码审计和安全测试的固定检查项。使用SAST静态应用安全测试工具扫描自定义过滤器代码使用DAST动态应用安全测试工具或IAST交互式应用安全测试工具对运行中的应用进行自动化漏洞扫描。最小权限原则为应用服务器、数据库等配置最小必需的权限。即使授权被绕过攻击者能造成的破坏也相对有限。5.4 针对路径标准化问题的通用防护代码示例你可以编写一个简单的Servlet Filter放在Shiro Filter之前对请求路径进行预处理和规范化确保传递给Shiro的路径是“干净的”。Component Order(Ordered.HIGHEST_PRECEDENCE) // 确保此Filter最先执行 public class PathSanitizationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String requestUri request.getRequestURI(); String contextPath request.getContextPath(); String path requestUri.substring(contextPath.length()); // 1. 进行规范化处理这里使用Java标准库的简化示例 // 注意此逻辑需与你的容器行为对齐可能需更复杂的实现 try { path new URI(path).normalize().getPath(); } catch (URISyntaxException e) { // 如果路径本身不合法直接拒绝 response.sendError(HttpServletResponse.SC_BAD_REQUEST, Invalid request path); return; } // 2. 检查是否仍包含危险序列可根据需要扩展 if (containsDangerousSequences(path)) { response.sendError(HttpServletResponse.SC_FORBIDDEN, Forbidden request pattern); return; } // 3. 使用净化后的路径注意修改HttpServletRequest的URI是复杂的通常做法是包装请求 // 更常见的做法是如果路径有问题就直接拒绝否则放行。 // 或者将净化后的路径作为一个属性设置到request中供后续Shiro Filter使用。 // 这里为了简单我们选择直接拒绝危险请求。 filterChain.doFilter(request, response); } private boolean containsDangerousSequences(String path) { // 定义你认为危险的路径序列 ListString dangerousPatterns Arrays.asList( /../, /.., ;/, %2e%2e, %3b, \\.. // 注意这里需要根据业务仔细定义避免误杀 ); String lowerPath path.toLowerCase(); for (String pattern : dangerousPatterns) { if (lowerPath.contains(pattern)) { return true; } } return false; } }重要提醒自定义路径清洗逻辑需要非常小心必须充分测试确保不会影响正常的、合法的业务请求。最好的方式仍然是升级到已修复的官方版本。6. 排查技巧与深度思考在实际运维和应急响应中如果怀疑系统存在此类授权绕过漏洞或者升级后需要验证修复效果可以遵循以下步骤。6.1 漏洞存在性排查版本确认首先检查项目中引入的shiro-core和shiro-web的版本。如果版本号低于1.9.0则理论上存在风险。配置审查检查ShiroFilterFactoryBean的过滤器链定义。重点关注那些保护管理后台、API接口的路径规则如/admin/**,/api/private/**。这些是攻击者的主要目标。动态测试使用上一节提到的Payload对上述受保护接口进行测试。使用普通用户权限或无权限会话进行访问观察是否返回了本应只有高权限用户才能看到的数据。测试时务必使用备份环境或测试环境避免对生产数据造成影响。日志分析查看应用日志和Shiro的日志如果开启了DEBUG级别。关注访问受保护路径的请求Shiro是否打印了匹配过滤器链和进行权限判定的日志。如果请求明显访问了/admin/xxx但Shiro的日志显示它匹配到了/public/**链或者根本没有经过权限判断那可能就是绕过的迹象。6.2 升级后验证功能回归测试确保所有正常的业务接口包括需要登录和权限校验的接口在升级后都能正常工作。漏洞复现测试使用之前有效的Payload再次测试确认请求已被正确拦截返回403、302跳转登录等。边缘Case测试测试一些边界情况如带有多余斜杠的路径/admin//list带有点号的路径/admin/./list包含URL编码的合法路径如果业务允许。确保修复没有引入新的问题例如将一些合法的、包含特殊字符的请求误拦截。6.3 深度思考权限设计的“失效边界”CVE-2022-32532给我们上了一课权限校验的失效不一定发生在复杂的加密算法被攻破时更多时候发生在这些“边缘”地带——不同组件对同一件事物的理解不一致。这引申出几个安全设计原则一致性原则在整个请求处理链路中对于关键信息如请求路径、用户标识的解析和传递必须保持一致。尽可能让权限校验组件使用与业务处理组件完全相同的源数据和解析逻辑。默认拒绝原则权限框架的默认行为应该是“拒绝”只有明确允许的才能通过。在配置路径规则时要警惕“先宽后严”导致的绕过。例如规则/public/**anon和/**authc的顺序就很重要如果颠倒/public/下的请求也会要求认证。纵深防御永远不要只依赖一层防御。在Filter层做校验在Controller层做二次校验在服务方法内部还可以根据业务上下文做最终校验。在网关层再做一次统一的认证和基础风控。持续更新与监控使用像Dependabot、Snyk等工具监控项目依赖的安全漏洞。建立快速响应机制确保在漏洞披露后能及时评估影响、测试补丁并安排升级。最后我想说的是研究像CVE-2022-32532这样的历史漏洞价值不在于多掌握一个攻击Payload而在于理解其背后“路径标准化不一致”这一大类问题的模式。下次当你自己设计一个API网关、一个权限中间件或者审查一段URL路由代码时你自然会多问一句“我这里处理的路径和后面业务组件理解的路径真的是一样的吗” 这种思维习惯才是安全工程师最宝贵的财富。
