1. 从一次常规资产梳理说起Actuator 暴露面到底有多大很多做安全测试或者后端开发的朋友第一次接触 SpringBoot Actuator 都是在一次例行的资产测绘或者接口梳理里。你手上拿到一个域名或者一组 IP 段跑完端口扫描、目录扫描之后发现某个路径返回了一串看起来像 JSON 的东西里面带着_links、self、health、info这些字段。这时候大概率就是撞上了 Actuator 的默认端点。它本身是 SpringBoot 官方提供的一套生产级监控和管理能力设计初衷是让运维和开发能实时看到应用的健康状态、指标数据、环境变量、Bean 加载情况等等。问题在于这套东西如果配置不当直接暴露在公网或者内网可达的位置就变成了一个信息泄露甚至进一步利用的入口。我写这篇东西的出发点很简单把 Actuator 未授权访问这件事从“怎么发现”到“怎么判断危害”再到“怎么利用已有信息做进一步动作”这条链路讲透。适合谁看一是做 Web 安全测试、渗透测试方向的朋友需要一套可复现的排查思路二是后端开发和运维想搞清楚自己项目里 Actuator 到底该怎么配才不至于出事三是对 SpringBoot 生态感兴趣、想了解生产环境常见配置风险的同学。全文会围绕实际动手过程展开涉及到的端点、参数、判断逻辑都会给到具体说明尽量做到看完就能上手对照检查。需要先明确一点Actuator 未授权访问本身是一个“配置类”问题不是 SpringBoot 框架的代码漏洞。官方文档里其实写得很清楚默认只暴露health和info而且这两个端点默认也不包含敏感信息。真正出问题的是开发者为了调试方便把management.endpoints.web.exposure.include设成了*同时又没有加任何认证鉴权或者把management.security.enabled关掉了。所以这类问题的核心不在于“攻”而在于“配”。理解这一点后面的所有操作你都能找到对应的防御落点。2. Actuator 端点体系与敏感信息分布2.1 默认端点与暴露机制SpringBoot Actuator 的端点分为几大类健康检查类、指标类、环境配置类、Bean 管理类、映射类、线程与堆转储类等。每个端点都有一个唯一的 ID比如health、metrics、env、beans、mappings、threaddump、heapdump、configprops、loggers、httptrace等等。这些端点默认通过 HTTP 暴露在/actuator/{id}路径下也可以通过 JMX 访问。Web 暴露的开关由management.endpoints.web.exposure.include和exclude控制默认 include 只有health和info。这里有个容易混淆的点management.endpoints.web.exposure.include*表示暴露所有端点但并不是所有端点都默认启用。比如shutdown端点默认是 disabled 的需要额外设置management.endpoint.shutdown.enabledtrue才能用。而heapdump和threaddump这类端点只要被 include 了默认就是可访问的。所以实际排查时不能只看 include 配置还要结合具体端点的 enabled 状态来判断。从版本演进来看SpringBoot 1.x 和 2.x 在 Actuator 的配置方式和默认行为上有明显差异。1.x 时代默认路径是根路径下的/{id}比如/env、/health而且management.security.enabled默认是 true但很多项目为了省事直接关掉了。2.x 之后统一挪到了/actuator前缀下默认只暴露 health 和 info安全性有所提升但一旦有人手动放开风险依然存在。所以看到/actuator/env这种路径基本可以判断是 2.x 及以上版本看到直接/env的可能是 1.x 或者改过 base-path。2.2 高价值端点逐个拆解在未授权访问场景下不同端点泄露的信息价值差异很大。我按实际利用价值从高到低排一下方便你排查时优先关注。env端点是我个人认为最值得先看的。它返回应用的环境变量和配置属性包括systemProperties、systemEnvironment、applicationConfig等分组。里面经常能翻到数据库连接串、Redis 密码、第三方 API Key、云服务 AK/SK 这类硬编码或通过环境变量注入的敏感信息。即使做了脱敏applicationConfig里也可能暴露配置中心的地址、命名空间、加密盐值等线索。heapdump端点更直接它允许下载整个 JVM 堆转储文件。堆里有什么运行时的对象实例、字符串常量、数据库连接池配置、会话信息甚至明文密码。拿到 heapdump 之后用 MAT 或者 VisualVM 打开搜索关键字就能捞出大量敏感数据。这个端点的危害等级是最高的因为它不依赖配置是否脱敏堆内存里的东西是实打实的。configprops端点展示所有ConfigurationPropertiesbean 的属性绑定情况包括数据源配置、邮件配置、缓存配置等。和env有重叠但结构更清晰有时候env里被脱敏的值在configprops里反而能看到。mappings端点列出所有RequestMapping映射关系等于把应用的接口清单直接交出来。对于后续做接口测试或者找未授权接口来说这是一份现成的字典。beans端点列出容器里所有 Bean 的名称、类型、依赖关系能帮你快速了解应用的技术栈和模块划分。threaddump返回当前所有线程的堆栈信息可以用来判断应用在跑什么任务、用了哪些中间件客户端。httptrace在 2.x 里叫httptrace记录最近的 HTTP 请求响应信息包括请求路径、方法、头信息、响应状态。如果开启了能看到其他用户的请求痕迹甚至包含 Cookie 和 Token。loggers端点可以动态修改日志级别这个在利用阶段很有用比如把某个包的日志调到 DEBUG 来观察更多信息或者配合其他操作做信息收集。shutdown端点如果启用且未授权可以直接关闭应用属于破坏性操作测试时要格外谨慎。2.3 版本差异与路径变化实际排查中路径判断是第一步。SpringBoot 2.x 默认 base-path 是/actuator所以完整路径是/actuator/env、/actuator/health。但开发者可以通过management.endpoints.web.base-path修改比如改成/manage、/monitor或者直接改成/。1.x 默认没有统一前缀直接就是/env、/health。另外还有management.server.port可以单独指定管理端口这时候 Actuator 就跑在另一个端口上和业务端口分离。我遇到过把 base-path 改成/api/actuator的也见过直接去掉前缀的。所以发现阶段不能只盯着/actuator要结合目录扫描结果和响应特征来判断。一个实用的技巧是访问/actuator根路径如果返回_links结构里面列出的就是当前暴露的端点列表这是最直接的确认方式。如果根路径 404可以试试/actuator/health返回{status:UP}就说明 Actuator 存在。3. 发现与验证从路径探测到端点确认3.1 被动发现与主动探测发现 Actuator 的途径主要有两类。被动方式是在做流量分析或者日志审计时看到请求路径里带了/actuator/或者/env、/health这类特征。主动方式就是拿字典去扫。字典不用太复杂核心就是那几个端点名加上常见的前缀组合。我常用的探测路径列表大概长这样/actuator/actuator/health/actuator/info/actuator/env/actuator/beans/actuator/mappings/actuator/configprops/actuator/metrics/actuator/threaddump/actuator/heapdump/actuator/loggers/actuator/httptrace/env/health/beans/mappings/configprops/metrics/threaddump/heapdump前缀变体也要覆盖/manage、/monitor、/admin、/api、/system、/internal等。实际扫描时返回 200 且内容类型是application/json或者application/vnd.spring-boot.actuator.v2json的基本可以确认。这里有个细节有些项目会配置management.endpoints.web.cors.allowed-origins或者加一些自定义的拦截器导致直接访问返回 401 或 403。这时候不要急着放弃可以试试加Origin头、改User-Agent、或者用不同的 HTTP 方法。我遇到过只允许内网 IP 访问的也遇到过只对特定路径放行的多试几种组合往往有收获。3.2 响应特征与确认方法确认一个端点是否真正可用不能只看状态码。200 返回空 JSON{}和 200 返回完整数据是两回事。以env为例如果返回的 JSON 里propertySources数组为空或者只有systemProperties且内容被过滤过那说明虽然端点暴露了但做了脱敏或者限制。如果能看到applicationConfig里带着具体的配置项和值那就是实打实的泄露。health端点比较特殊它默认只返回{status:UP}但如果配置了management.endpoint.health.show-detailsalways就会把数据库、Redis、磁盘空间等组件的详细状态都带出来。这个信息本身不算特别敏感但能帮你确认应用依赖了哪些中间件。heapdump的确认更直接访问/actuator/heapdump如果返回一个二进制文件响应头里Content-Type是application/octet-streamContent-Disposition带attachment; filenameheapdump那就说明可以直接下载。文件大小从几十 MB 到几个 GB 不等取决于堆内存配置和运行时长。threaddump返回 JSON 格式的线程列表mappings返回contexts结构beans返回beans数组。每个端点的响应结构都有固定特征熟悉之后一眼就能判断。3.3 未授权判定与边界确认“未授权”这三个字的判定标准其实需要明确。严格来说未授权访问是指在没有提供任何有效凭证的情况下能够访问到本应受保护的资源。但在实际测试中有些系统会返回 200 但内容为空有些会返回 401 但带上WWW-Authenticate头提示认证方式还有些会返回 403 但泄露了路径存在的信息。我的判断逻辑是这样的先不带任何 Cookie 和 Authorization 头访问目标端点如果返回 200 且响应体包含实质内容就初步判定为未授权。然后换一个干净的会话比如无痕窗口或者新的 curl 请求再验证一次排除缓存和会话残留的影响。如果两次都一致基本可以确认。边界确认还包括这个端点是否对公网开放还是只在内网可达。如果是内网危害评估要结合内网横向移动的可能性来看。如果是公网那优先级就要往上提。另外还要看是否有 WAF 或者网关层面的拦截有些请求在浏览器里能通但用脚本跑就被拦了这种差异也要记录。4. 信息提取与利用链路拆解4.1 env 与 configprops 的敏感信息挖掘拿到env端点的完整输出后不要从头到尾硬看那样效率太低。我的做法是先看propertySources数组里每个元素的name字段通常会有systemProperties、systemEnvironment、applicationConfig: [classpath:/application.yml]、applicationConfig: [classpath:/application-dev.yml]这样的分组。优先关注applicationConfig开头的因为这里面是应用自己的配置。然后在 JSON 里搜索关键词password、passwd、secret、key、token、accessKey、secretKey、connectionString、url、jdbc、redis、mongodb、mysql、datasource。这些词一搜基本能把敏感项筛出来。注意有些值会被******脱敏但脱敏只针对env端点的某些版本configprops有时候不脱敏两个端点对照着看。我实际遇到过在env里翻到阿里云 OSS 的 AccessKey ID 和 Secret虽然 Secret 被脱敏了但 ID 还在配合其他信息可以进一步推测。也见过spring.datasource.password直接明文躺在那里这种就是直接可以连数据库了。还有spring.redis.password、spring.mail.password、wechat.appsecret这类都是高价值目标。configprops的结构是{ contexts: { application: { beans: { ... } } } }每个 bean 下面有prefix和properties。搜索逻辑和env类似重点看properties里的值。4.2 heapdump 下载与离线分析heapdump的利用分两步下载和分析。下载直接用 curl 或者浏览器curl -o heapdump.hprof http://target/actuator/heapdump文件可能很大建议先发一个 HEAD 请求看Content-Length心里有个数。下载过程中注意网络稳定性断了大文件重下很痛苦。分析工具首选 Eclipse Memory AnalyzerMAT免费且功能强大。打开 hprof 文件后用 OQLObject Query Language或者直接搜字符串。我常用的几个搜索方向搜password、secret、token、accessKey等关键词看哪些字符串对象包含这些内容搜数据库连接串特征比如jdbc:mysql://、jdbc:postgresql://、mongodb://、redis://搜Authorization、Bearer、Cookie等 HTTP 头相关的字符串搜类名比如DataSource、RedisTemplate、MongoClient看这些对象的字段值MAT 的Dominator Tree和Histogram视图能帮你快速定位大对象和可疑对象。如果堆里有明文密码通常在char[]或者String对象里能直接看到。我试过在一个 heapdump 里搜到 MySQL 的 root 密码和 Redis 的 requirepass整个过程不到十分钟。4.3 mappings 与 beans 的辅助价值mappings端点返回的接口清单对于后续做接口测试非常有用。它会把每个RequestMapping的路径、方法、参数、返回类型都列出来。你可以把这份清单导出成文本然后和业务功能对照找那些没有鉴权的内部接口。比如/internal/、/admin/、/debug/开头的路径往往是权限控制的薄弱点。beans端点能帮你确认应用用了哪些组件。比如看到DruidDataSource就知道用了 Druid 连接池看到RedisTemplate就知道有 Redis 操作看到MongoTemplate就知道连了 MongoDB。这些信息结合env里的配置能拼出一张完整的应用架构图。threaddump在利用阶段的价值在于判断应用当前在跑什么。比如看到大量http-nio-8080-exec线程说明有并发请求看到ScheduledTask线程说明有定时任务看到KafkaConsumer线程说明在消费消息。这些信息对于判断应用状态和选择后续操作时机有帮助。4.4 loggers 动态调整与信息放大loggers端点允许在运行时修改日志级别这个功能在利用阶段可以放大信息收集效果。比如把org.springframework.web调到 DEBUG能看到请求处理的详细日志把com.example调到 TRACE能看到业务逻辑的详细执行过程。如果应用把日志输出到文件或者控制台而这些日志又能通过其他方式读到那就能获得更多线索。修改日志级别的请求格式curl -X POST http://target/actuator/loggers/com.example \ -H Content-Type: application/json \ -d {configuredLevel:DEBUG}这个操作本身不会直接泄露数据但能改变应用的日志行为配合其他手段使用。需要注意的是修改日志级别可能会影响性能测试完记得改回去。5. 常见问题与排查技巧实录5.1 端点返回 404 或 401 怎么办404 通常意味着路径不对或者端点没暴露。先确认 base-path 是否被改过试试/manage/actuator、/api/actuator这些变体。如果还是 404可能是端点被 exclude 了或者应用根本没引入 Actuator 依赖。401 说明有认证拦截这时候可以看看响应头里的WWW-Authenticate字段判断是 Basic 认证还是其他方式。有些项目用 Spring Security 保护了 Actuator但只保护了部分端点可以试试其他端点是否放行。还有一种情况是返回 200 但内容是{status:UP}这种说明端点存在但被限制了输出。这时候可以试试加?showDetailstrue或者改Accept头有时候能绕过简单的限制逻辑。5.2 heapdump 下载中断或文件损坏大文件下载中断是常见问题。我的做法是先用curl -I看Content-Length和Accept-Ranges如果支持断点续传就用curl -C -继续下。如果不支持就换个网络环境或者用wget试试。下载完成后用file命令确认文件类型正常的 hprof 文件开头是JAVA PROFILE。如果文件大小明显不对或者 MAT 打不开那就是下载不完整需要重来。另外注意有些应用配置了management.endpoint.heapdump.enabledfalse这时候访问会返回 404 或者 403。还有的应用在堆转储时做了权限校验需要特定角色才能下载。5.3 敏感信息被脱敏后的应对SpringBoot 2.x 对env端点的敏感值默认做了脱敏显示为******。但这个脱敏是有条件的它只对 key 名匹配特定模式的属性生效比如包含password、secret、key的。如果开发者把密码字段命名成pwd、pass、credential这种可能就不会被脱敏。所以看到******不要放弃试试从configprops、heapdump或者其他端点找补。还有一种情况是脱敏逻辑被自定义覆盖了比如开发者实现了自己的SanitizingFunction把脱敏范围缩小了。这种在env里能看到原始值的概率就更大。5.4 利用过程中的风险控制做这类测试时有几个红线要守住。第一不要用shutdown端点关闭生产应用这是破坏性操作除非有明确授权。第二不要用heapdump里拿到的密码去登录生产数据库这属于越界操作。第三修改loggers级别后记得恢复避免影响业务。第四下载的 heapdump 文件要妥善保管里面可能包含用户隐私数据测试完及时删除。我的习惯是发现阶段只做只读操作确认危害即可利用阶段在授权范围内进行每一步都记录操作时间和内容测试结束后提交详细报告包括端点列表、泄露信息类型、建议修复方案。5.5 常见问题速查表问题现象可能原因排查方向访问/actuator返回 404base-path 被修改或 Actuator 未引入尝试常见前缀变体检查依赖端点返回 401有认证拦截查看WWW-Authenticate头尝试其他端点env返回空propertySources端点被限制或脱敏检查configprops、heapdumpheapdump下载中断文件过大或网络不稳用curl -C -续传换网络环境敏感值显示******默认脱敏生效换字段名搜索查configpropsmappings返回空端点未启用或版本差异确认 SpringBoot 版本和配置loggersPOST 返回 405方法不允许或端点禁用检查是否启用了 POST 支持6. 修复建议与加固思路6.1 最小化暴露原则最直接的修复方式就是按需暴露。生产环境只保留health和info其他端点一律 exclude。配置示例management: endpoints: web: exposure: include: health,info exclude: env,beans,mappings,configprops,heapdump,threaddump,loggers,httptrace如果确实需要某些端点做监控比如metrics和prometheus那就单独 include并且加上认证。不要图省事写include: *这是最常见的错误来源。6.2 认证与网络层防护如果 Actuator 必须暴露那就加认证。Spring Security 可以很方便地保护 Actuator 端点Configuration public class ActuatorSecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.requestMatcher(EndpointRequest.toAnyEndpoint()) .authorizeRequests() .anyRequest().hasRole(ACTUATOR) .and() .httpBasic(); } }网络层防护也很重要。把 Actuator 绑定到内网管理端口通过management.server.port和management.server.address限制访问来源。再配合防火墙策略只允许特定 IP 段访问管理端口。6.3 敏感信息脱敏与审计对于必须暴露的端点确保脱敏逻辑覆盖到位。SpringBoot 2.x 默认对env和configprops里的敏感 key 做脱敏但不要依赖默认行为最好自定义SanitizingFunction把公司内部约定的敏感字段都加进去。同时开启 Actuator 的访问审计记录谁在什么时候访问了哪个端点便于事后追溯。6.4 版本升级与配置检查清单SpringBoot 1.x 升级到 2.x 能解决一部分默认配置问题但核心还是配置本身。我整理了一份检查清单部署前对照过一遍management.endpoints.web.exposure.include是否只包含必要端点management.endpoint.heapdump.enabled是否为 falsemanagement.endpoint.shutdown.enabled是否为 falsemanagement.endpoint.health.show-details是否设置为never或when-authorizedmanagement.server.port是否与业务端口分离management.server.address是否限制为内网地址是否有 Spring Security 或其他认证机制保护 Actuator敏感配置是否通过配置中心加密存储而非明文放在application.yml这份清单看起来简单但实际能全部做到的项目并不多。我审过的项目里至少一半以上在include这一项就出了问题。7. 个人实操体会与后续扩展方向做 Actuator 相关的测试多了之后我最大的体会是这类问题的核心不在于技术难度而在于配置管理的规范性。很多团队在开发阶段为了方便调试把能开的端点全开了上线时忘了收回去。或者运维和开发之间的职责边界不清都以为对方会处理安全配置。所以排查的时候除了看技术层面的暴露情况也要理解背后的管理流程问题。另一个体会是heapdump的价值被严重低估了。很多人看到env里脱敏了就放弃了其实堆转储里往往藏着更完整的信息。我建议把heapdump分析作为标准流程的一部分用 MAT 建几个常用的 OQL 查询模板下次直接套用效率会高很多。后续如果还想深入可以往这几个方向扩展一是研究不同 SpringBoot 版本下 Actuator 的默认行为差异整理成版本对照表二是把heapdump分析脚本化用 Python 或者 Shell 自动提取敏感字符串三是结合其他未授权访问问题比如配置中心、消息队列的管理界面做横向对比形成一套完整的“未授权访问类问题”排查方法论。这些内容后续有机会再单独展开聊。