Spring Boot Actuator 未授权访问漏洞 — 外网验证与修复方案

一、外网验证步骤（先确认漏洞存在）

在动手修复前，必须先从外网确认漏洞确实存在，避免误操作。

1. 识别目标是否为 Spring Boot 应用

识别方式	特征
Favicon 图标	浏览器标签页显示绿色树叶图标
错误页	访问不存在路径返回 "Whitelabel Error Page"
指纹搜索	app="vmware-SpringBoot-Framework" 或 body="Whitelabel Error Page"

2. 核心验证命令（从外网执行）

# ① 探测 Actuator 根路径是否暴露
curl -i http://目标IP:端口/actuator

# ② 验证 /env 端点（高危，泄露数据库密码等）
curl -i http://目标IP:端口/actuator/env

# ③ 验证 /health 端点
curl -i http://目标IP:端口/actuator/health

# ④ 验证 /heapdump 端点（可下载内存快照，离线分析密码）
curl -i http://目标IP:端口/actuator/heapdump -o heapdump.hprof

# ⑤ 验证 /shutdown 端点（可直接关闭服务）
curl -X POST http://目标IP:端口/actuator/shutdown

# ⑥ 验证 Jolokia 端点（RCE 利用入口）
curl -i http://目标IP:端口/actuator/jolokia

判定标准 ： 以上任一接口返回 200 而非 401/403/404，即确认存在未授权访问漏洞。

⚠️ 特别注意 ： /env 和 /heapdump 是最危险的两个端点。/env 可直接看到数据库账号密码（即使加密也可能被破解），/heapdump 下载后用 MAT 工具可搜出明文密码。如果存在 /jolokia，攻击者可直接 远程执行任意代码（RCE），这是最高危场景。

二、修复方案（按推荐优先级排列）

方案 A：最彻底 --- 完全禁用 Actuator（生产环境首选）

如果线上不需要监控功能，直接关掉，从根上消除风险。

application.yml 配置：

management:
  server:
    port: -1    # 关闭 Actuator 端口，所有端点返回 404

或 application.properties：

management.server.port=-1

验证：重启后 curl /actuator/env 返回 404，修复通过。

---

方案 B：保留必要监控 + 严格限制暴露范围（推荐）

只开放 health 和 info 两个端点，关闭详情，并修改默认路径避免被扫描器命中。

application.yml 配置：

management:
  endpoints:
    web:
      exposure:
        include: health,info    # 只暴露这两个
        # exclude: env,heapdump,threaddump,mappings,shutdown,jolokia
  endpoints:
    web:
      base-path: /monitor-internal   # 修改默认路径，绕过扫描
  endpoint:
    health:
      show-details: never    # 关键：不返回数据库/磁盘等详情，只返回 UP/DOWN
    env:
      enabled: false
    shutdown:
      enabled: false

show-details 三档对比：

值	返回内容	安全性	适用场景
NEVER	{"status":"UP"}	🟢 高	生产环境推荐
WHEN_AUTHORIZED	未登录看简略，登录看详情	🟡 中	需集成 Spring Security
ALWAYS	完整详情（DB、磁盘等）	🔴 低	仅开发/测试环境

方案 C：Spring Security 认证（需要登录才能访问）

适合必须保留全部端点但需严格控制访问的场景。

第一步：引入依赖（pom.xml）

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

第二步：application.yml 配置

spring:
  security:
    user:
      name: admin
      password: ${随机强密码，不要硬编码}

management:
  endpoints:
    web:
      exposure:
        include: health,info,env
  endpoint:
    health:
      show-details: never

重启后访问任意 /actuator/* 端点都会弹出登录框。

---

方案 D：Nginx 拦截（不改应用代码的应急方案）

如果暂时无法改动应用，可在 Nginx 层直接阻断。

# 拦截所有 actuator 路径
location ^~ /actuator {
    deny all;
    return 403;
}

# 如果用了自定义路径
location ^~ /monitor-internal {
    allow 127.0.0.1;      # 只允许本机
    deny all;
    return 403;
}

reload：nginx -s reload

---

三、修复后验证（必须执行）

修复并重启应用后，从外网重新执行验证命令：

端点	修复前	修复后（合格）
/actuator	200	404（方案A）或 401（方案C）
/actuator/env	200（泄露密码）	404
/actuator/heapdump	200（可下载）	404
/actuator/shutdown	200	404
/actuator/health	200 + 详情	200，仅 {"status":"UP"}
/actuator/jolokia	200（RCE入口）	404

同时用原扫描工具复扫一次，确认漏洞消失。

---

四、Jar 包部署场景的特殊处理

如果客户是 Jar 包部署，无法直接改配置文件：

# 1. 解压 Jar 包中的配置
unzip -q app.jar BOOT-INF/classes/application.yml

# 2. 编辑配置，追加安全配置（参考方案B）
vim BOOT-INF/classes/application.yml

# 3. 重新打包
zip -q app.jar BOOT-INF/classes/application.yml

# 4. 重启应用并验证

五、建议

场景	推荐方案
生产环境无监控需求	方案 A（直接关掉） --- 最干净，扫描直接过
需要健康检查上报	方案 B（限制暴露 + 改路径） --- 兼顾安全与运维
必须保留全部端点	方案 C（Security 认证） --- 成本最高但最灵活
临时应急来不及改代码	方案 D（Nginx 拦截） --- 先堵住再说

如果客户环境中存在 /jolokia 端点，这属于 RCE 级别高危，建议优先按方案 A 处理，同时排查是否已被利用（检查异常出站连接、新增进程、定时任务等）。