Shiro授权绕过漏洞CVE-2022-32532：路径标准化不一致的深度剖析与防护实践

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请求，都会先经过这个过滤器。它的核心工作流程可以概括为以下几个步骤：

1. 接收请求：获取原始的HttpServletRequest对象，其中包含了用户请求的完整信息，如URI、参数、方法等。
2. 路径匹配：Shiro会根据配置文件中定义的一系列FilterChain规则，来判断当前请求的路径应该由哪个（或哪组）过滤器来处理。这些规则通常使用Ant风格的路径匹配符，比如/admin/** = authc, roles[admin]。
3. 执行过滤链：如果路径匹配成功，则依次执行该链上定义的过滤器（如authc认证过滤器、perms权限过滤器等）。任何一个过滤器拒绝请求，都会中断后续处理，通常导向登录页或错误页。
4. 路径标准化（关键步骤）：在进行路径匹配之前，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.0）：

  1. Shiro收到请求，获取到request.getRequestURI()，假设得到/contextPath/admin/%3b..%2flist。
  2. Shiro开始进行标准化。在旧版本的WebUtils（getPathWithinApplication方法）或PathMatchingFilter的路径获取逻辑中，对于URL解码和路径规范化的顺序或细节处理可能存在瑕疵。在某些处理流程中，;（分号）在J2EE规范中常用于分割路径和参数（如/path;jsessionid=xxx），Shiro的标准化过程可能会将/admin/;../list中的;及其之后的部分进行特殊处理或截断，导致标准化后的结果可能变成了/admin或者仍然包含特殊序列而未能正确回溯（..）。
  3. 标准化后的路径（例如/admin）再去匹配过滤器链。它匹配到了/admin/**这条规则，因此Shiro会要求用户具备admin角色。
  4. 如果用户未登录或不具备admin角色，Shiro过滤器链将拒绝此请求，返回403或跳转登录。

• Tomcat（Spring MVC）的视角：

  1. Tomcat接收到同样的请求。
  2. Tomcat（或Spring MVC的DispatcherServlet）也有自己的请求路径解析逻辑。它对路径的规范化处理可能与Shiro不同。
  3. 关键点在于，Tomcat在处理/admin/;../list时，可能会将;..进行解析。在某些版本或配置下，Tomcat可能会将;视为路径参数的分隔符，并在进行路径规范化时，将;..及其之前的部分（/admin/;）作为一个“可忽略”的路径参数节点，或者以某种方式使得..回退到了上一级。最终，Tomcat成功将请求映射到了/list这个Servlet或Controller上。但更常见且危险的情况是，经过Tomcat的URL解码和规范化后，路径可能直接变成了/admin/list。
  4. 于是，一个被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> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 引入存在漏洞的Shiro版本 --> <dependency> <groupId>org.apache.shiro</groupId> <artifactId>shiro-spring-boot-web-starter</artifactId> <version>1.8.0</version> <!-- 关键：使用1.9.0之前的版本 --> </dependency> </dependencies>

2. 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"); // 定义权限规则 Map<String, 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, user

4. 控制器代码 (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：正常访问测试

1. 未登录访问/admin/list：会被Shiro重定向到/login。符合预期。
2. 使用普通用户user登录后访问/admin/list：会返回Unauthorized!，因为user角色不是admin。符合预期。
3. 使用管理员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/;../list

• Payload 2 (变体):

  curl -v "http://localhost:8080/admin/%3b/list"

  • 实际路径：/admin/;/list

• Payload 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或更高。

<version>1.9.0</version> <!-- 或更新版本 -->

重新启动应用，再次使用相同的Payload进行测试。此时，请求应该会被Shiro正确拦截，返回登录页面或未授权提示，证明漏洞已修复。

4. 漏洞挖掘与代码审计视角

从防御和代码审计的角度，我们不仅要会复现，更要学会如何发现这类问题。这不仅仅适用于Shiro，也适用于任何自定义的权限拦截过滤器或网关。

4.1 审计关键代码点

当审计一个使用Shiro（或其他权限框架）的项目时，应重点关注以下位置：

1. shiro.ini或ShiroFilterFactoryBean配置：检查URL模式与控制器路径的对应关系是否清晰，是否有过于宽泛的匹配（如/**放行过早）。
2. 自定义Filter：如果项目继承了Shiro的PathMatchingFilter或AccessControlFilter，需要仔细审查其isAccessAllowed或onAccessDenied方法中，获取请求路径的逻辑。是否直接使用了request.getRequestURI()？是否经过了正确的标准化处理？
3. WebUtils#getPathWithinApplication的调用点：这是Shiro中获取应用内路径的核心方法。在旧版本中，这里就是风险点。审计时看项目是否使用了存在漏洞的Shiro版本。
4. 权限注解与拦截器：检查@RequiresPermissions、@RequiresRoles等注解的使用，确保它们被正确地织入到了执行链中。但CVE-2022-32532这类路径绕过通常发生在Filter链层面，注解层面可能无法防御。

4.2 构造测试用例的思路

在黑白盒测试中，可以系统性地测试路径标准化差异：

1. 特殊字符插入：在受保护的路径中插入各种特殊字符，观察响应差异。
   • 分号;:/admin/;/list,/admin/%3b/list
   • 冒号:(较少见):/admin/:/list
   • 反斜杠\(Windows路径特性，在Web中常被规范化):/admin\list(可能被转为/admin/list)
   • URL编码的斜杠：%2f(/),%5c(\)
   • 多重编码：%253b(对%3b再次编码，即;的双重编码)
2. 路径遍历序列：结合特殊字符使用..进行回溯。
   • /admin/..;/list
   • /admin/%2e%2e/list
   • /admin/;../list
   • /admin/..%2flist
3. 后缀/参数混淆：尝试在路径后添加后缀或参数，干扰匹配。
   • /admin/list.js(如果配置是/admin/**，可能仍匹配)
   • /admin/list;jsessionid=xxx
   • /admin/list?x=../(注意，Shiro默认的getPathWithinApplication会去掉查询参数，但自定义Filter可能处理不当)
4. 大小写混淆：对于大小写敏感/不敏感的服务端或配置，尝试/ADMIN/list、/Admin/list等。
5. 空格与特殊空白符：%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, proxies=proxies, timeout=5, allow_redirects=False) # 判断逻辑：如果访问受保护路径返回非重定向(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容器的行为保持一致。

升级检查清单：

1. 版本确认：检查所有项目的pom.xml或build.gradle，确保Shiro依赖版本≥1.9.0。
2. 兼容性测试：升级后，必须进行全面的功能测试和回归测试。重点测试所有涉及URL权限控制的接口，确保原有正常的权限校验依然有效，没有因为路径处理逻辑改变而误拦截合法请求。
3. 依赖传递：检查是否通过其他依赖（如某个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 架构层防御：纵深防御体系

1. WAF（Web应用防火墙）：在应用前端部署WAF，可以配置规则拦截包含..、;、%00等可疑路径遍历或编码特征的请求。这是应对已知漏洞攻击模式的有效缓解措施。
2. API网关统一鉴权：将所有流量先经过API网关。在网关层完成统一的身份认证（如JWT校验）和基础路由鉴权。这样，即使后端某个服务的权限校验存在漏洞，攻击者也必须先突破网关层的防线。
3. 定期安全扫描与代码审计：将类似“路径标准化绕过”作为代码审计和安全测试的固定检查项。使用SAST（静态应用安全测试）工具扫描自定义过滤器代码，使用DAST（动态应用安全测试）工具或IAST（交互式应用安全测试）工具对运行中的应用进行自动化漏洞扫描。
4. 最小权限原则：为应用服务器、数据库等配置最小必需的权限。即使授权被绕过，攻击者能造成的破坏也相对有限。

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) { // 定义你认为危险的路径序列 List<String> 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 漏洞存在性排查

1. 版本确认：首先检查项目中引入的shiro-core和shiro-web的版本。如果版本号低于1.9.0，则理论上存在风险。
2. 配置审查：检查ShiroFilterFactoryBean的过滤器链定义。重点关注那些保护管理后台、API接口的路径规则（如/admin/**,/api/private/**）。这些是攻击者的主要目标。
3. 动态测试：使用上一节提到的Payload，对上述受保护接口进行测试。使用普通用户权限或无权限会话进行访问，观察是否返回了本应只有高权限用户才能看到的数据。测试时务必使用备份环境或测试环境，避免对生产数据造成影响。
4. 日志分析：查看应用日志和Shiro的日志（如果开启了DEBUG级别）。关注访问受保护路径的请求，Shiro是否打印了匹配过滤器链和进行权限判定的日志。如果请求明显访问了/admin/xxx，但Shiro的日志显示它匹配到了/public/**链或者根本没有经过权限判断，那可能就是绕过的迹象。

6.2 升级后验证

1. 功能回归测试：确保所有正常的业务接口，包括需要登录和权限校验的接口，在升级后都能正常工作。
2. 漏洞复现测试：使用之前有效的Payload再次测试，确认请求已被正确拦截（返回403、302跳转登录等）。
3. 边缘Case测试：测试一些边界情况，如：
   • 带有多余斜杠的路径：/admin//list
   • 带有点号的路径：/admin/./list
   • 包含URL编码的合法路径（如果业务允许）。
   • 确保修复没有引入新的问题，例如将一些合法的、包含特殊字符的请求误拦截。

6.3 深度思考：权限设计的“失效边界”

CVE-2022-32532给我们上了一课：权限校验的失效，不一定发生在复杂的加密算法被攻破时，更多时候发生在这些“边缘”地带——不同组件对同一件事物的理解不一致。这引申出几个安全设计原则：

1. 一致性原则：在整个请求处理链路中，对于关键信息（如请求路径、用户标识）的解析和传递必须保持一致。尽可能让权限校验组件使用与业务处理组件完全相同的源数据和解析逻辑。
2. 默认拒绝原则：权限框架的默认行为应该是“拒绝”，只有明确允许的才能通过。在配置路径规则时，要警惕“先宽后严”导致的绕过。例如，规则/public/**=anon和/**=authc的顺序就很重要，如果颠倒，/public/下的请求也会要求认证。
3. 纵深防御：永远不要只依赖一层防御。在Filter层做校验，在Controller层做二次校验，在服务方法内部还可以根据业务上下文做最终校验。在网关层再做一次统一的认证和基础风控。
4. 持续更新与监控：使用像Dependabot、Snyk等工具监控项目依赖的安全漏洞。建立快速响应机制，确保在漏洞披露后能及时评估影响、测试补丁并安排升级。

最后，我想说的是，研究像CVE-2022-32532这样的历史漏洞，价值不在于多掌握一个攻击Payload，而在于理解其背后“路径标准化不一致”这一大类问题的模式。下次当你自己设计一个API网关、一个权限中间件，或者审查一段URL路由代码时，你自然会多问一句：“我这里处理的路径，和后面业务组件理解的路径，真的是一样的吗？” 这种思维习惯，才是安全工程师最宝贵的财富。