上周帮一家互联网公司做红队评估。他们的微服务架构挺讲究，API网关负责统一认证，后端十几个服务各管一摊。我盯着网关的认证配置看了半天，然后往URL里加了一个斜杠，就越过了认证层，直接打进了只有管理员才能访问的内部接口。
整个过程没有改参数，没有编恶意Payload，甚至没用任何漏洞扫描器。就是这么一加一减，网关的"统一认证"就形同虚设。今天把这套路径前缀绕过认证的技术拆开，从原理到实战到防御，全部公开。
一、API网关是怎么工作的？
在微服务架构里，API网关是所有外部请求的第一站。它负责三件事：
-
路由匹配：把请求转发到对应的后端服务。
-
认证鉴权：校验用户身份和权限，没登录或没权限的直接拒绝。
-
流量治理：限流、熔断、日志等。
认证这一关通常是通过"路径前缀"来区分的。比如：
-
/api/public/**：公开接口，不需要登录。 -
/api/user/**：普通用户接口，需要用户Token。 -
/api/admin/**：管理员接口，需要管理员权限。
网关会在配置里写上类似规则：
- path: /api/public/**
auth: false
- path: /api/admin/**
auth: true
role: admin这段配置看起来无懈可击。但问题在于，网关和后端服务对"路径"的理解可能不一样 。当你在/api/admin和admin之间塞进一些奇怪的字符，网关可能认不出来这是/api/admin/**，就把它当成公开路径放行了；而后端服务却能正确解析出真实的路径，把它当成/api/admin/**来处理。
这个差异，就是绕过认证的入口。
二、四种经典的路径前缀绕过手法
1. 编码绕过
最基础也最常见。把路径中的关键字符做URL编码，网关在匹配路由时可能不会解码，而后端服务会解码。比如：
/api/ad%6din/users网关看到的是/api/ad%6din/users，不匹配/api/admin/**，可能当成普通路径放行。后端Nginx或Tomcat收到后解码为/api/admin/users，管理员接口被访问。
2. 双重编码绕过
如果网关做了一次解码再匹配，那就试双重编码：
/api/ad%256din/users网关解码一次变成/api/ad%6din/users，还是不匹配/api/admin/**。后端再解码一次变成/api/admin/users，成功绕过。
3. 路径参数污染
利用路径参数注入额外内容。比如网关配置为/api/user/{userId}需要认证，/api/public/**不需要。攻击者构造：
/api/public/../admin/users网关匹配时看到/api/public/**，判定为公开路径放行。后端服务解析..，路径规范化为/api/admin/users，直接进了管理员接口。
4. 斜杠变异
这是最"隐蔽"的一种。不同服务对连续斜杠、结尾斜杠的处理不同：
/api//admin/users
/api/admin//users
/api/admin/users/有些网关在做路径匹配时，会把连续斜杠合并，或者把结尾斜杠去掉，导致匹配结果和实际转发路径不一致。攻击者可以利用这个差异，让网关误判路径类型。
三、实战：一次真实的路径前缀绕过攻击
以下是在一个测试环境里的实战过程。
目标架构：使用Kong作为API网关，后端服务是Spring Boot。Kong的认证配置如下：
-
/public/**：不需要认证。 -
/admin/**：需要管理员Token。
第一步：正常测试
我直接请求/admin/users，没有Token，返回401 Unauthorized。带普通用户Token，返回403 Forbidden。合情合理。
第二步：尝试编码绕过
我试了/ad%6din/users，返回404 Not Found。说明Kong没有直接放行，或者后端路由不认这个编码路径。
第三步：尝试路径参数污染
再试/public/../admin/users。Kong匹配到/public/**，判定为公开路径，直接转发给后端Spring Boot。Spring Boot在解析路径时，会把/public/../admin/users规范化为/admin/users。于是，管理员接口被无Token访问，返回了所有用户数据。
这一步成功了。
第四步：扩大战果
既然能绕过认证访问管理员接口，我继续测试其他敏感接口：
-
/public/../admin/export-users：导出所有用户，返回CSV文件。 -
/public/../admin/config：查看系统配置，包含数据库连接字符串。 -
/public/../admin/role/update：修改用户角色，可以将自己提升为管理员。
一整套组合拳下来，整个后台全部沦陷。最讽刺的是，网关上每一笔请求都记了日志，但没有一条告警------因为从网关视角看，这些都是合法的/public/**请求。
四、为什么2026年还有这种低级错误？
1. 网关与后端对路径解析的逻辑不一致。 这永远是核心原因。不同的框架（Nginx、Spring、Express、Django）对URL编码、路径规范化、斜杠处理有不同的实现。网关在做路由匹配时用的是自己的规则，转发到后端后又由后端重新解析一次。两次解析不一致，就会产生安全缺口。
2. 配置复杂度高，安全测试覆盖不足。 一个大型微服务架构里，网关路由规则可能上百条，每条都涉及认证、限流、转发等。安全团队通常只测业务功能，很少有人专门审计网关配置的路径匹配逻辑。
3. 开发框架的默认配置不安全。 有些微服务框架在生成网关配置时，默认使用前缀匹配，且没有对路径规范化做处理。开发者没有意识到这些默认配置的风险，直接上线。
五、挖掘这类漏洞的思路
第一步：枚举路径结构。 从JS文件、API文档或错误信息里，找出所有/admin、/internal、/manage等敏感路径前缀，以及/public、/open等公开路径前缀。
第二步：测试多种路径变体。 对每个敏感路径，尝试以下变体：
/admin/users
//admin/users
/admin//users
/admin/users/
/ad%6din/users
/ad%256din/users
/public/../admin/users
/public/%2e%2e/admin/users
/api/v1/../admin/users第三步：观察响应差异。 对比正常请求和变体请求的响应。如果变体请求返回了敏感数据而不是401/403，说明绕过了认证。
第四步：测试不同HTTP方法。 有些网关只对GET做认证，POST/PUT/DELETE可能直接放行。把请求方法换一换试试。
第五步：检查后端框架。 如果知道后端是Spring Boot，就重点测路径规范化差异；如果是Nginx，就测双斜杠和编码差异。
六、防御方案
1. 网关统一路径规范化。 在网关层对请求路径做一次严格的规范化处理，包括解码URL编码、移除路径穿越（..）、合并连续斜杠等，然后再做路由匹配。确保网关和后端看到的是同一条路径。
2. 拒绝可疑路径。 在网关层直接拒绝包含..、编码斜杠、连续斜杠等可疑字符的请求，返回400。
3. 后端服务二次鉴权。 即使网关已经做了认证，后端每个服务也应当自己校验权限。不能完全信任网关的转发结果。这是纵深防御的基本原则。
4. 定期审计网关配置。 用自动化工具扫描网关路由规则，检查是否存在前缀匹配过宽、路径规范化缺失、认证配置遗漏等问题。
七、写在最后
API网关是微服务架构的心脏，也是安全防御的第一道防线。但心脏也会生病，防线也会有缝隙。路径前缀绕过认证这门老手艺，2026年依旧在各大企业的网关配置里频繁现身。它不需要多高的技术，只需要多一点的耐心和细心。
下次测微服务架构时，别只盯着业务接口的SQL注入和越权。花点时间看看网关的配置，试试往URL里加点奇怪的字符。你可能会发现，那些被网关拒之门外的管理员接口，其实只隔着一个斜杠的距离。
严正声明
本文所述技术仅用于合法授权的安全测试，所有案例均已脱敏处理。未经授权利用路径绕过漏洞入侵计算机系统属于违法行为，与作者无关。请遵守法律法规，在授权范围内进行安全评估。