1. 项目概述一次典型的SpringBoot Actuator未授权访问实战复盘最近在内部的一次安全评估中我遇到了一个非常典型的SpringBoot Actuator未授权访问漏洞。这个漏洞本身并不复杂但它的发现、利用以及后续可能引发的连锁反应却是一个值得所有开发者和安全工程师深入思考的案例。SpringBoot Actuator作为应用监控和管理的利器如果配置不当就会像给自家大门装了一把所有人都知道的通用钥匙将应用的内部状态、敏感信息甚至控制权直接暴露在外。这次实战我从一个暴露的/actuator端点开始一步步深入到获取环境变量、数据库连接信息甚至尝试了可能的RCE路径。整个过程就像一次标准的安全渗透测试演练清晰地展示了从信息泄露到权限提升的完整攻击链。无论你是负责开发SpringBoot应用的工程师还是从事安全测试或运维的同学理解这个漏洞的原理、危害和修复方法都是构建安全应用防线的基础课。2. 漏洞原理与核心风险点深度解析2.1 SpringBoot Actuator是什么它为何会暴露信息SpringBoot Actuator是SpringBoot官方提供的一个用于监控和管理生产级应用的子项目。它的设计初衷是好的为运维人员提供一套标准化的HTTP或JMX端点Endpoints来查看应用的健康状况、指标、日志级别、环境配置等信息。想象一下你开发了一个复杂的微服务上线后如何知道它是否在健康运行内存使用情况如何当前有哪些Bean被加载Actuator就是回答这些问题的“仪表盘”。Actuator通过一系列内置的端点来提供这些功能。在SpringBoot 2.x中常见的端点包括/actuator/health: 应用健康状态。/actuator/info: 应用自定义信息。/actuator/metrics: 应用各项指标。/actuator/env:暴露全部环境属性。这是关键风险点包含操作系统环境变量、application.properties/yml中的所有配置。/actuator/beans: 显示应用中所有的Spring Beans。/actuator/mappings: 显示所有的RequestMapping路径。/actuator/loggers: 查看和动态修改日志级别。/actuator/heapdump: 下载堆转储文件。/actuator/trace: 显示最近的HTTP请求跟踪信息早期版本。/actuator/configprops: 显示所有ConfigurationProperties的配置。问题就出在安全配置上。在SpringBoot 1.x时代许多端点默认就是开启且无需认证的。到了2.x出于安全考虑默认只有/actuator/health和/actuator/info是暴露在Web上的通过HTTP访问其他端点需要显式配置或通过JMX访问。但是很多开发者为了图方便或者在测试环境调试时会直接通过配置management.endpoints.web.exposure.include*来暴露所有端点并且忽略了配置访问权限控制如集成Spring Security。这就导致了未授权访问漏洞任何能访问到应用IP和端口的人都可以直接读取这些敏感端点。注意即使不暴露*只暴露了envbeansconfigprops等端点风险同样巨大。攻击者无需认证即可获取大量用于下一步攻击的“地图”。2.2 未授权访问的真正危害不止于信息泄露很多开发者可能会觉得“不就是看到一些配置信息吗有什么大不了的” 这种想法非常危险。Actuator未授权访问的危害是链式、递进的它为攻击者提供了发动更致命攻击的“弹药库”。敏感信息泄露这是最直接的危害。通过/actuator/env端点攻击者可以获取数据库连接字符串直接拿到数据库的IP、端口、用户名和密码。第三方API密钥如短信服务、邮件服务、云存储OSS/AWS S3的AccessKey/SecretKey。加密密钥如JWT签名密钥、数据库加密盐值。拿到JWT密钥意味着可以伪造任意用户身份的Token。内部服务地址其他微服务的注册地址便于攻击者横向移动。服务器环境变量可能包含运维密码、秘钥文件路径等。应用内部结构探测通过/actuator/beans和/actuator/mappings攻击者可以清晰地了解应用的Spring容器结构和所有API接口相当于拿到了应用的“源代码结构图”为寻找其他漏洞如未授权API、SQL注入点提供了极大便利。动态修改应用行为/actuator/loggers端点允许动态修改日志级别。攻击者可以将关键包的日志级别调整为DEBUG从而在后续的请求中让应用打印出更详细的敏感信息例如SQL语句可能包含参数值、完整的请求响应体等。拒绝服务DoS与资源耗尽/actuator/heapdump端点可以触发堆转储生成一个巨大的.hprof文件。如果攻击者频繁请求此端点会大量消耗服务器磁盘I/O和内存可能导致服务响应缓慢甚至直接崩溃。潜在的远程代码执行RCE这是最严重的危害。在某些特定版本和配置下Actuator的端点可能与其他漏洞结合导致RCE。例如历史上存在过通过/actuator/env端点修改环境属性配合spring.cloud.bootstrap.enabledtrue等配置利用反序列化漏洞执行任意代码的案例。虽然这种利用条件相对苛刻但一旦满足后果是灾难性的。3. 漏洞发现与手动利用全流程3.1 信息收集与端点识别实战中发现Actuator漏洞的第一步是信息收集。攻击者或安全测试人员通常会从以下角度入手端口扫描与服务识别使用nmap等工具对目标IP段进行常见端口如8080, 8443, 9000等扫描并通过横幅Banner信息或HTTP响应头识别SpringBoot应用。SpringBoot应用通常有特定的错误页面和X-Application-Context等响应头。nmap -sV -p 8080,8443,9000 目标IP目录与路径爆破这是最直接有效的方法。使用字典对目标应用的根路径进行爆破寻找是否存在/actuator、/manage、/admin等常见的管理端点路径。常用的工具有dirsearch、gobuster或ffuf。dirsearch -u http://target:8080 -e * -w /path/to/springboot_dict.txt字典内容应包含/actuator /actuator/ /management /admin /monitor /metrics /env /health实操心得很多开发人员会自定义management.endpoints.web.base-path例如改为/manage。因此一个包含常见管理路径的字典非常重要。同时观察网站JS文件、HTML注释或Robots.txt有时也能发现线索。访问默认端点如果发现/actuator直接访问。在SpringBoot 2.x中它会返回一个JSON列出所有已暴露的端点及其链接。这就像拿到了所有房间的钥匙清单。GET http://target:8080/actuator预期响应{ “_links”: { “self”: { “href”: “http://target:8080/actuator”, “templated”: false }, “beans”: { “href”: “http://target:8080/actuator/beans”, “templated”: false }, “env”: { “href”: “http://target:8080/actuator/env”, “templated”: false }, “health”: { “href”: “http://target:8080/actuator/health”, “templated”: false }, “info”: { “href”: “http://target:8080/actuator/info”, “templated”: false }, “mappings”: { “href”: “http://target:8080/actuator/mappings”, “templated”: false } } }看到这样的响应基本可以确定存在未授权访问。3.2 敏感信息提取与分析一旦确认端点可访问下一步就是系统地提取和分析敏感信息。我通常会按照以下优先级进行首要目标/actuator/env。这是信息量最大的端点。直接访问并保存整个JSON响应。然后使用jq命令或任何JSON解析工具进行快速过滤。curl -s http://target:8080/actuator/env | jq ‘.’ env.json在env.json中重点搜索以下关键词password,passwd,pwdkey,secret,token,credentialjdbc,mysql,redis,mongodb(数据库连接串)url,endpointaccessKey,secretKeyspring.datasource(数据库配置)mail(邮件配置)一个真实的危险示例{ “name”: “spring.datasource.password”, “value”: “Root123456” }拿到这个攻击者已经可以直连业务数据库了。次要目标/actuator/configprops。这个端点以更结构化的方式展示了所有带ConfigurationProperties的配置类。在这里你可能会发现一些在env中不那么直观的配置比如第三方SDK的完整配置对象。侦察目标/actuator/mappings和/actuator/beans。mappings列出所有控制器Controller的请求映射。仔细审查寻找可能存在的未授权API、调试接口如/debug/**、上传接口等。这为后续的API测试提供了直接目标。beans展示Spring容器中所有的Bean定义。可以了解应用使用了哪些框架和组件如ShiroFilterFactoryBean,RedisTemplate有助于判断是否存在已知漏洞的组件版本。试探性操作/actuator/loggers。尝试访问GET /actuator/loggers/com.example.demo查看日志级别并尝试POST /actuator/loggers/com.example.demo修改其级别为DEBUG。如果成功说明攻击者甚至能动态影响应用行为为后续捕捉更详细的错误信息或调试日志创造条件。curl -X POST http://target:8080/actuator/loggers/com.example \ -H “Content-Type: application/json” \ -d ‘{“configuredLevel”: “DEBUG”}’3.3 利用链构建与深度利用尝试在获取足够信息后攻击者会尝试构建利用链将信息泄露漏洞升级为更严重的漏洞。场景一数据库接管直接从env中获取到完整的JDBC URL、用户名和明文密码。攻击者可以使用数据库客户端如MySQL Workbench, Navicat直接连接进行数据窃取、篡改或删除。如果数据库权限较高还可能通过SELECT INTO OUTFILE等方式向服务器写入Webshell需满足特定条件。场景二横向移动获取到内部其他微服务的地址和认证信息如HTTP Basic Auth、API Token。攻击者可以以此为跳板攻击内网中其他更脆弱的服务扩大战果。场景三配合其他漏洞RCE历史案例回顾这是一个需要特定条件的利用路径但极具警示意义。在SpringBoot 1.x特别是1.5.x及部分2.x早期版本中如果同时满足以下条件暴露了/actuator/env或1.x的/env端点且可写POST方法允许。应用依赖了spring-cloud-starter-netflix-eureka-client等组件且spring.cloud.bootstrap.enabledtrue或通过环境变量可设置。攻击者能够控制一个恶意的HTTP服务如恶意的Eureka注册中心。攻击者可以通过POST /actuator/env设置spring.cloud.bootstrap.environment等属性指向恶意的配置服务器。当应用重启或刷新配置时会从恶意服务器加载包含恶意代码的配置从而导致远程代码执行。虽然Spring官方后续版本修复了此类问题但它深刻揭示了“配置即代码”理念在失控时带来的巨大风险。重要提示在实战中直接利用Actuator进行RCE已不常见但信息泄露足以导致“社会工程学攻击”或“撞库攻击”。例如获取到的邮箱密码可能被用于尝试登录公司的VPN或Git仓库。4. 自动化工具辅助与手动验证4.1 常用扫描工具与脚本为了提高效率安全人员会使用一些自动化工具进行初步探测。但切记工具只是辅助深入分析和验证必须靠手动。被动扫描器如AWVS、AppScan、Xray等它们的POC库中通常包含SpringBoot Actuator未授权访问的检测规则。在常规Web漏洞扫描中就可能被发现。主动扫描脚本SpringBoot-Actuator-ExploitGitHub上一些开源工具可以自动探测常见端点并提取敏感信息。自定义Python脚本对于有编程能力的安全工程师写一个简单的脚本进行批量检测和关键信息提取是基本操作。import requests import json import sys def check_actuator(url): endpoints [‘/actuator’, ‘/actuator/env’, ‘/actuator/configprops’] for ep in endpoints: try: full_url url.rstrip(‘/’) ep resp requests.get(full_url, timeout5) if resp.status_code 200: print(f‘[] Found: {full_url}’) if ‘env’ in ep or ‘configprops’ in ep: data resp.json() # 简单过滤密码关键词 print(scan_for_secrets(data)) except Exception as e: continue if __name__ ‘__main__’: target sys.argv[1] if len(sys.argv) 1 else ‘http://localhost:8080’ check_actuator(target)工具使用的局限性自动化工具可能会误报或漏报。例如当端点路径被自定义或者返回状态码不是200可能是401/403但响应体仍有信息时工具可能无法识别。因此手动使用浏览器或curl进行验证是不可或缺的步骤。4.2 手动验证与深入利用技巧手动验证不仅能确认漏洞还能发现自动化工具忽略的细节。响应状态码不是唯一标准有些应用可能对/actuator返回403但对具体的子端点如/actuator/health返回200。需要逐个尝试常见子端点。关注响应头与响应体格式即使返回JSON也要看内容。有时/actuator端点可能被部分保护返回{“_links”: {}}空链接但通过猜测或爆破其他端点名如/actuator/heapdump可能直接访问成功。尝试HTTP方法除了GET对某些端点如/actuator/loggers尝试POST方法看是否能修改配置。对/actuator/refresh配置刷新端点尝试POST看是否能触发配置重新加载在某些配置下可能敏感。信息关联分析将从env获取的配置信息与从mappings获取的API路径结合起来看。例如发现一个file.upload.path的配置指向/tmp/uploads同时在mappings中发现一个POST /api/upload的接口那么就可以重点测试这个文件上传接口是否存在漏洞。留意堆转储文件如果/actuator/heapdump可访问下载下来的.hprof文件可以使用MATMemory Analyzer Tool或JVisualVM打开。在堆内存中有可能找到保存在内存中的敏感信息如数据库连接池中的密码明文如果某些连接池未及时清理、用户的Session对象等。这属于更深层次的信息泄露。5. 漏洞修复与安全加固方案发现漏洞后更重要的是如何修复和防范。以下方案按安全强度从高到低排列。5.1 根本解决方案禁用或严格管控Actuator端点生产环境禁用不必要的Web端点这是最安全的方式。在application-prod.yml中严格限制暴露的端点通常只保留health和info。# application-prod.yml management: endpoints: web: exposure: include: health,info # 只暴露健康和基本信息端点 base-path: /internal-monitor # 建议修改默认路径增加爆破难度 endpoint: health: show-details: never # 健康端点不展示详细信息 env: enabled: false # 明确禁用env端点 beans: enabled: false集成Spring Security进行访问控制如果确实需要暴露更多端点给运维人员必须集成Spring Security并配置严格的基于角色的访问控制RBAC。Configuration EnableWebSecurity public class ActuatorSecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(“/actuator/health”, “/actuator/info”).permitAll() // 健康检查允许所有人访问 .antMatchers(“/actuator/**”).hasRole(“ACTUATOR_ADMIN”) // 其他端点需要特定角色 .anyRequest().authenticated() // 其他应用接口也需要认证 .and() .httpBasic(); // 使用HTTP Basic认证生产环境建议用更安全的如JWT } Bean Override public UserDetailsService userDetailsService() { UserDetails user User.withDefaultPasswordEncoder() // 注意这只是示例生产环境必须用加密密码 .username(“actuator-admin”) .password(“StrongPassword123!”) .roles(“ACTUATOR_ADMIN”) .build(); return new InMemoryUserDetailsManager(user); } }关键点为Actuator管理创建独立的、高强度的账号密码。生产环境切勿使用默认密码或弱密码。考虑将management.endpoints.web.base-path修改为不易猜测的路径并纳入权限控制。使用网络层隔离通过防火墙、安全组或Kubernetes NetworkPolicy限制只有特定的运维网络或跳板机IP才能访问应用服务器的Actuator端口通常是应用端口。这是纵深防御的重要一环。5.2 敏感信息脱敏与审计配置信息脱敏对于必须出现在env中的敏感配置SpringBoot提供了脱敏机制。使用spring.config.import或自定义EnvironmentPostProcessor将密码、密钥等属性在加载后替换为******。spring: datasource: password: ‘${DB_PASSWORD:}’ # 从环境变量读取在Actuator的/env端点输出时SpringBoot默认会对名为password,secret,key,token等标准属性进行脱敏显示为******”。但自定义属性需要手动配置management.endpoint.env.show-values属性并配合spring.jackson.default-property-inclusion来控制。定期安全审计与扫描将Actuator端点检查纳入日常的安全扫描流程。使用IAST交互式应用安全测试或SCA软件成分分析工具在CI/CD流水线中检测是否存在不安全的Actuator配置。同时定期对线上服务进行授权后的漏洞扫描。5.3 应急响应与后续监控如果已经发生了未授权访问应该立即采取以下措施紧急修复立即修改所有泄露的密码、密钥。包括数据库密码、第三方服务API Key、内部系统认证Token等。不要抱有侥幸心理。日志审计检查应用日志和网络流量日志看是否有异常IP在特定时间访问了Actuator端点。尝试追溯攻击者的行为轨迹。漏洞复盘分析漏洞产生的原因是配置错误、默认设置还是对安全文档的忽视更新项目脚手架、部署模板和运维手册将安全配置作为默认项固化下来。监控告警配置对Actuator管理端点的访问监控告警。任何非授权IP或异常时间段的访问尝试都应触发实时告警通知安全运维人员。6. 常见误区、排查清单与进阶思考6.1 开发者常见的安全误区误区一“测试环境没关系”测试环境往往使用弱密码或与生产环境共享部分配置。攻击者拿下测试环境后可能以此为跳板攻击生产网络或窃取测试数据其中也可能包含真实数据。误区二“用了内网就安全”内网并非绝对安全。在云原生环境下容器网络可能比想象中更开放。内部员工的误操作、已入侵的其他内网机器都可能成为攻击源。误区三“只开health和info就安全”这比暴露所有端点安全得多但/actuator根路径本身仍会返回这两个端点的链接。建议同时修改base-path或确保根路径也受权限控制。误区四“依赖默认的安全配置”SpringBoot在安全上做了很多改进但“默认安全”不等于“绝对安全”。开发者有责任根据自身业务场景进行显式的、严格的安全配置。6.2 安全配置快速自查清单在将SpringBoot应用部署上线前请对照此清单检查[ ]端点暴露management.endpoints.web.exposure.include是否只包含了必要的端点如health,info是否使用了通配符*[ ]访问控制是否集成了Spring Security并对/actuator/**路径配置了强认证和授权如RBAC[ ]路径修改是否修改了management.endpoints.web.base-path不使用默认的/actuator[ ]敏感信息脱敏/actuator/env端点输出的敏感属性密码、密钥是否已正确脱敏显示为******[ ]健康端点细节management.endpoint.health.show-details在生产环境是否设置为never或when-authorized[ ]网络隔离服务器防火墙或云安全组是否限制了只有运维IP能访问应用的管理端口[ ]依赖管理使用的SpringBoot Actuator及相关组件如Spring Cloud是否为已修复已知安全漏洞的最新稳定版本6.3 进阶思考从漏洞看研发安全流程这个漏洞暴露出的是更深层次的研发流程问题。它不应该仅仅被看作一个配置错误而应促使我们思考安全左移安全要求是否在项目设计、编码阶段就被纳入考虑是否使用了带有安全基线检查的项目模板配置即代码如何管理不同环境开发、测试、生产的配置文件敏感配置是否通过安全的Vault如HashiCorp Vault, AWS Secrets Manager注入而非硬编码在文件中自动化检查能否在CI/CD流水线中加入自动化安全扫描步骤对编译产物或部署配置进行检测自动发现此类不安全配置并阻断部署默认安全原则我们的基础设施、容器镜像、部署脚本是否遵循“默认安全”原则即默认配置就是最安全的配置需要更多功能时才手动开启。SpringBoot Actuator未授权访问漏洞像一面镜子映照出应用在便捷性与安全性之间的平衡。便捷的工具用好了是利器用不好就是后门。作为技术人员我们享受框架带来的开发效率提升的同时必须对其潜在的安全风险保持清醒的认识和敬畏。每一次配置的疏忽都可能为攻击者打开一扇门。真正的安全始于每一行谨慎的代码每一次认真的配置审查。
SpringBoot Actuator未授权访问漏洞：原理、危害与安全加固实战
发布时间：2026/6/21 23:34:11
1. 项目概述一次典型的SpringBoot Actuator未授权访问实战复盘最近在内部的一次安全评估中我遇到了一个非常典型的SpringBoot Actuator未授权访问漏洞。这个漏洞本身并不复杂但它的发现、利用以及后续可能引发的连锁反应却是一个值得所有开发者和安全工程师深入思考的案例。SpringBoot Actuator作为应用监控和管理的利器如果配置不当就会像给自家大门装了一把所有人都知道的通用钥匙将应用的内部状态、敏感信息甚至控制权直接暴露在外。这次实战我从一个暴露的/actuator端点开始一步步深入到获取环境变量、数据库连接信息甚至尝试了可能的RCE路径。整个过程就像一次标准的安全渗透测试演练清晰地展示了从信息泄露到权限提升的完整攻击链。无论你是负责开发SpringBoot应用的工程师还是从事安全测试或运维的同学理解这个漏洞的原理、危害和修复方法都是构建安全应用防线的基础课。2. 漏洞原理与核心风险点深度解析2.1 SpringBoot Actuator是什么它为何会暴露信息SpringBoot Actuator是SpringBoot官方提供的一个用于监控和管理生产级应用的子项目。它的设计初衷是好的为运维人员提供一套标准化的HTTP或JMX端点Endpoints来查看应用的健康状况、指标、日志级别、环境配置等信息。想象一下你开发了一个复杂的微服务上线后如何知道它是否在健康运行内存使用情况如何当前有哪些Bean被加载Actuator就是回答这些问题的“仪表盘”。Actuator通过一系列内置的端点来提供这些功能。在SpringBoot 2.x中常见的端点包括/actuator/health: 应用健康状态。/actuator/info: 应用自定义信息。/actuator/metrics: 应用各项指标。/actuator/env:暴露全部环境属性。这是关键风险点包含操作系统环境变量、application.properties/yml中的所有配置。/actuator/beans: 显示应用中所有的Spring Beans。/actuator/mappings: 显示所有的RequestMapping路径。/actuator/loggers: 查看和动态修改日志级别。/actuator/heapdump: 下载堆转储文件。/actuator/trace: 显示最近的HTTP请求跟踪信息早期版本。/actuator/configprops: 显示所有ConfigurationProperties的配置。问题就出在安全配置上。在SpringBoot 1.x时代许多端点默认就是开启且无需认证的。到了2.x出于安全考虑默认只有/actuator/health和/actuator/info是暴露在Web上的通过HTTP访问其他端点需要显式配置或通过JMX访问。但是很多开发者为了图方便或者在测试环境调试时会直接通过配置management.endpoints.web.exposure.include*来暴露所有端点并且忽略了配置访问权限控制如集成Spring Security。这就导致了未授权访问漏洞任何能访问到应用IP和端口的人都可以直接读取这些敏感端点。注意即使不暴露*只暴露了envbeansconfigprops等端点风险同样巨大。攻击者无需认证即可获取大量用于下一步攻击的“地图”。2.2 未授权访问的真正危害不止于信息泄露很多开发者可能会觉得“不就是看到一些配置信息吗有什么大不了的” 这种想法非常危险。Actuator未授权访问的危害是链式、递进的它为攻击者提供了发动更致命攻击的“弹药库”。敏感信息泄露这是最直接的危害。通过/actuator/env端点攻击者可以获取数据库连接字符串直接拿到数据库的IP、端口、用户名和密码。第三方API密钥如短信服务、邮件服务、云存储OSS/AWS S3的AccessKey/SecretKey。加密密钥如JWT签名密钥、数据库加密盐值。拿到JWT密钥意味着可以伪造任意用户身份的Token。内部服务地址其他微服务的注册地址便于攻击者横向移动。服务器环境变量可能包含运维密码、秘钥文件路径等。应用内部结构探测通过/actuator/beans和/actuator/mappings攻击者可以清晰地了解应用的Spring容器结构和所有API接口相当于拿到了应用的“源代码结构图”为寻找其他漏洞如未授权API、SQL注入点提供了极大便利。动态修改应用行为/actuator/loggers端点允许动态修改日志级别。攻击者可以将关键包的日志级别调整为DEBUG从而在后续的请求中让应用打印出更详细的敏感信息例如SQL语句可能包含参数值、完整的请求响应体等。拒绝服务DoS与资源耗尽/actuator/heapdump端点可以触发堆转储生成一个巨大的.hprof文件。如果攻击者频繁请求此端点会大量消耗服务器磁盘I/O和内存可能导致服务响应缓慢甚至直接崩溃。潜在的远程代码执行RCE这是最严重的危害。在某些特定版本和配置下Actuator的端点可能与其他漏洞结合导致RCE。例如历史上存在过通过/actuator/env端点修改环境属性配合spring.cloud.bootstrap.enabledtrue等配置利用反序列化漏洞执行任意代码的案例。虽然这种利用条件相对苛刻但一旦满足后果是灾难性的。3. 漏洞发现与手动利用全流程3.1 信息收集与端点识别实战中发现Actuator漏洞的第一步是信息收集。攻击者或安全测试人员通常会从以下角度入手端口扫描与服务识别使用nmap等工具对目标IP段进行常见端口如8080, 8443, 9000等扫描并通过横幅Banner信息或HTTP响应头识别SpringBoot应用。SpringBoot应用通常有特定的错误页面和X-Application-Context等响应头。nmap -sV -p 8080,8443,9000 目标IP目录与路径爆破这是最直接有效的方法。使用字典对目标应用的根路径进行爆破寻找是否存在/actuator、/manage、/admin等常见的管理端点路径。常用的工具有dirsearch、gobuster或ffuf。dirsearch -u http://target:8080 -e * -w /path/to/springboot_dict.txt字典内容应包含/actuator /actuator/ /management /admin /monitor /metrics /env /health实操心得很多开发人员会自定义management.endpoints.web.base-path例如改为/manage。因此一个包含常见管理路径的字典非常重要。同时观察网站JS文件、HTML注释或Robots.txt有时也能发现线索。访问默认端点如果发现/actuator直接访问。在SpringBoot 2.x中它会返回一个JSON列出所有已暴露的端点及其链接。这就像拿到了所有房间的钥匙清单。GET http://target:8080/actuator预期响应{ “_links”: { “self”: { “href”: “http://target:8080/actuator”, “templated”: false }, “beans”: { “href”: “http://target:8080/actuator/beans”, “templated”: false }, “env”: { “href”: “http://target:8080/actuator/env”, “templated”: false }, “health”: { “href”: “http://target:8080/actuator/health”, “templated”: false }, “info”: { “href”: “http://target:8080/actuator/info”, “templated”: false }, “mappings”: { “href”: “http://target:8080/actuator/mappings”, “templated”: false } } }看到这样的响应基本可以确定存在未授权访问。3.2 敏感信息提取与分析一旦确认端点可访问下一步就是系统地提取和分析敏感信息。我通常会按照以下优先级进行首要目标/actuator/env。这是信息量最大的端点。直接访问并保存整个JSON响应。然后使用jq命令或任何JSON解析工具进行快速过滤。curl -s http://target:8080/actuator/env | jq ‘.’ env.json在env.json中重点搜索以下关键词password,passwd,pwdkey,secret,token,credentialjdbc,mysql,redis,mongodb(数据库连接串)url,endpointaccessKey,secretKeyspring.datasource(数据库配置)mail(邮件配置)一个真实的危险示例{ “name”: “spring.datasource.password”, “value”: “Root123456” }拿到这个攻击者已经可以直连业务数据库了。次要目标/actuator/configprops。这个端点以更结构化的方式展示了所有带ConfigurationProperties的配置类。在这里你可能会发现一些在env中不那么直观的配置比如第三方SDK的完整配置对象。侦察目标/actuator/mappings和/actuator/beans。mappings列出所有控制器Controller的请求映射。仔细审查寻找可能存在的未授权API、调试接口如/debug/**、上传接口等。这为后续的API测试提供了直接目标。beans展示Spring容器中所有的Bean定义。可以了解应用使用了哪些框架和组件如ShiroFilterFactoryBean,RedisTemplate有助于判断是否存在已知漏洞的组件版本。试探性操作/actuator/loggers。尝试访问GET /actuator/loggers/com.example.demo查看日志级别并尝试POST /actuator/loggers/com.example.demo修改其级别为DEBUG。如果成功说明攻击者甚至能动态影响应用行为为后续捕捉更详细的错误信息或调试日志创造条件。curl -X POST http://target:8080/actuator/loggers/com.example \ -H “Content-Type: application/json” \ -d ‘{“configuredLevel”: “DEBUG”}’3.3 利用链构建与深度利用尝试在获取足够信息后攻击者会尝试构建利用链将信息泄露漏洞升级为更严重的漏洞。场景一数据库接管直接从env中获取到完整的JDBC URL、用户名和明文密码。攻击者可以使用数据库客户端如MySQL Workbench, Navicat直接连接进行数据窃取、篡改或删除。如果数据库权限较高还可能通过SELECT INTO OUTFILE等方式向服务器写入Webshell需满足特定条件。场景二横向移动获取到内部其他微服务的地址和认证信息如HTTP Basic Auth、API Token。攻击者可以以此为跳板攻击内网中其他更脆弱的服务扩大战果。场景三配合其他漏洞RCE历史案例回顾这是一个需要特定条件的利用路径但极具警示意义。在SpringBoot 1.x特别是1.5.x及部分2.x早期版本中如果同时满足以下条件暴露了/actuator/env或1.x的/env端点且可写POST方法允许。应用依赖了spring-cloud-starter-netflix-eureka-client等组件且spring.cloud.bootstrap.enabledtrue或通过环境变量可设置。攻击者能够控制一个恶意的HTTP服务如恶意的Eureka注册中心。攻击者可以通过POST /actuator/env设置spring.cloud.bootstrap.environment等属性指向恶意的配置服务器。当应用重启或刷新配置时会从恶意服务器加载包含恶意代码的配置从而导致远程代码执行。虽然Spring官方后续版本修复了此类问题但它深刻揭示了“配置即代码”理念在失控时带来的巨大风险。重要提示在实战中直接利用Actuator进行RCE已不常见但信息泄露足以导致“社会工程学攻击”或“撞库攻击”。例如获取到的邮箱密码可能被用于尝试登录公司的VPN或Git仓库。4. 自动化工具辅助与手动验证4.1 常用扫描工具与脚本为了提高效率安全人员会使用一些自动化工具进行初步探测。但切记工具只是辅助深入分析和验证必须靠手动。被动扫描器如AWVS、AppScan、Xray等它们的POC库中通常包含SpringBoot Actuator未授权访问的检测规则。在常规Web漏洞扫描中就可能被发现。主动扫描脚本SpringBoot-Actuator-ExploitGitHub上一些开源工具可以自动探测常见端点并提取敏感信息。自定义Python脚本对于有编程能力的安全工程师写一个简单的脚本进行批量检测和关键信息提取是基本操作。import requests import json import sys def check_actuator(url): endpoints [‘/actuator’, ‘/actuator/env’, ‘/actuator/configprops’] for ep in endpoints: try: full_url url.rstrip(‘/’) ep resp requests.get(full_url, timeout5) if resp.status_code 200: print(f‘[] Found: {full_url}’) if ‘env’ in ep or ‘configprops’ in ep: data resp.json() # 简单过滤密码关键词 print(scan_for_secrets(data)) except Exception as e: continue if __name__ ‘__main__’: target sys.argv[1] if len(sys.argv) 1 else ‘http://localhost:8080’ check_actuator(target)工具使用的局限性自动化工具可能会误报或漏报。例如当端点路径被自定义或者返回状态码不是200可能是401/403但响应体仍有信息时工具可能无法识别。因此手动使用浏览器或curl进行验证是不可或缺的步骤。4.2 手动验证与深入利用技巧手动验证不仅能确认漏洞还能发现自动化工具忽略的细节。响应状态码不是唯一标准有些应用可能对/actuator返回403但对具体的子端点如/actuator/health返回200。需要逐个尝试常见子端点。关注响应头与响应体格式即使返回JSON也要看内容。有时/actuator端点可能被部分保护返回{“_links”: {}}空链接但通过猜测或爆破其他端点名如/actuator/heapdump可能直接访问成功。尝试HTTP方法除了GET对某些端点如/actuator/loggers尝试POST方法看是否能修改配置。对/actuator/refresh配置刷新端点尝试POST看是否能触发配置重新加载在某些配置下可能敏感。信息关联分析将从env获取的配置信息与从mappings获取的API路径结合起来看。例如发现一个file.upload.path的配置指向/tmp/uploads同时在mappings中发现一个POST /api/upload的接口那么就可以重点测试这个文件上传接口是否存在漏洞。留意堆转储文件如果/actuator/heapdump可访问下载下来的.hprof文件可以使用MATMemory Analyzer Tool或JVisualVM打开。在堆内存中有可能找到保存在内存中的敏感信息如数据库连接池中的密码明文如果某些连接池未及时清理、用户的Session对象等。这属于更深层次的信息泄露。5. 漏洞修复与安全加固方案发现漏洞后更重要的是如何修复和防范。以下方案按安全强度从高到低排列。5.1 根本解决方案禁用或严格管控Actuator端点生产环境禁用不必要的Web端点这是最安全的方式。在application-prod.yml中严格限制暴露的端点通常只保留health和info。# application-prod.yml management: endpoints: web: exposure: include: health,info # 只暴露健康和基本信息端点 base-path: /internal-monitor # 建议修改默认路径增加爆破难度 endpoint: health: show-details: never # 健康端点不展示详细信息 env: enabled: false # 明确禁用env端点 beans: enabled: false集成Spring Security进行访问控制如果确实需要暴露更多端点给运维人员必须集成Spring Security并配置严格的基于角色的访问控制RBAC。Configuration EnableWebSecurity public class ActuatorSecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(“/actuator/health”, “/actuator/info”).permitAll() // 健康检查允许所有人访问 .antMatchers(“/actuator/**”).hasRole(“ACTUATOR_ADMIN”) // 其他端点需要特定角色 .anyRequest().authenticated() // 其他应用接口也需要认证 .and() .httpBasic(); // 使用HTTP Basic认证生产环境建议用更安全的如JWT } Bean Override public UserDetailsService userDetailsService() { UserDetails user User.withDefaultPasswordEncoder() // 注意这只是示例生产环境必须用加密密码 .username(“actuator-admin”) .password(“StrongPassword123!”) .roles(“ACTUATOR_ADMIN”) .build(); return new InMemoryUserDetailsManager(user); } }关键点为Actuator管理创建独立的、高强度的账号密码。生产环境切勿使用默认密码或弱密码。考虑将management.endpoints.web.base-path修改为不易猜测的路径并纳入权限控制。使用网络层隔离通过防火墙、安全组或Kubernetes NetworkPolicy限制只有特定的运维网络或跳板机IP才能访问应用服务器的Actuator端口通常是应用端口。这是纵深防御的重要一环。5.2 敏感信息脱敏与审计配置信息脱敏对于必须出现在env中的敏感配置SpringBoot提供了脱敏机制。使用spring.config.import或自定义EnvironmentPostProcessor将密码、密钥等属性在加载后替换为******。spring: datasource: password: ‘${DB_PASSWORD:}’ # 从环境变量读取在Actuator的/env端点输出时SpringBoot默认会对名为password,secret,key,token等标准属性进行脱敏显示为******”。但自定义属性需要手动配置management.endpoint.env.show-values属性并配合spring.jackson.default-property-inclusion来控制。定期安全审计与扫描将Actuator端点检查纳入日常的安全扫描流程。使用IAST交互式应用安全测试或SCA软件成分分析工具在CI/CD流水线中检测是否存在不安全的Actuator配置。同时定期对线上服务进行授权后的漏洞扫描。5.3 应急响应与后续监控如果已经发生了未授权访问应该立即采取以下措施紧急修复立即修改所有泄露的密码、密钥。包括数据库密码、第三方服务API Key、内部系统认证Token等。不要抱有侥幸心理。日志审计检查应用日志和网络流量日志看是否有异常IP在特定时间访问了Actuator端点。尝试追溯攻击者的行为轨迹。漏洞复盘分析漏洞产生的原因是配置错误、默认设置还是对安全文档的忽视更新项目脚手架、部署模板和运维手册将安全配置作为默认项固化下来。监控告警配置对Actuator管理端点的访问监控告警。任何非授权IP或异常时间段的访问尝试都应触发实时告警通知安全运维人员。6. 常见误区、排查清单与进阶思考6.1 开发者常见的安全误区误区一“测试环境没关系”测试环境往往使用弱密码或与生产环境共享部分配置。攻击者拿下测试环境后可能以此为跳板攻击生产网络或窃取测试数据其中也可能包含真实数据。误区二“用了内网就安全”内网并非绝对安全。在云原生环境下容器网络可能比想象中更开放。内部员工的误操作、已入侵的其他内网机器都可能成为攻击源。误区三“只开health和info就安全”这比暴露所有端点安全得多但/actuator根路径本身仍会返回这两个端点的链接。建议同时修改base-path或确保根路径也受权限控制。误区四“依赖默认的安全配置”SpringBoot在安全上做了很多改进但“默认安全”不等于“绝对安全”。开发者有责任根据自身业务场景进行显式的、严格的安全配置。6.2 安全配置快速自查清单在将SpringBoot应用部署上线前请对照此清单检查[ ]端点暴露management.endpoints.web.exposure.include是否只包含了必要的端点如health,info是否使用了通配符*[ ]访问控制是否集成了Spring Security并对/actuator/**路径配置了强认证和授权如RBAC[ ]路径修改是否修改了management.endpoints.web.base-path不使用默认的/actuator[ ]敏感信息脱敏/actuator/env端点输出的敏感属性密码、密钥是否已正确脱敏显示为******[ ]健康端点细节management.endpoint.health.show-details在生产环境是否设置为never或when-authorized[ ]网络隔离服务器防火墙或云安全组是否限制了只有运维IP能访问应用的管理端口[ ]依赖管理使用的SpringBoot Actuator及相关组件如Spring Cloud是否为已修复已知安全漏洞的最新稳定版本6.3 进阶思考从漏洞看研发安全流程这个漏洞暴露出的是更深层次的研发流程问题。它不应该仅仅被看作一个配置错误而应促使我们思考安全左移安全要求是否在项目设计、编码阶段就被纳入考虑是否使用了带有安全基线检查的项目模板配置即代码如何管理不同环境开发、测试、生产的配置文件敏感配置是否通过安全的Vault如HashiCorp Vault, AWS Secrets Manager注入而非硬编码在文件中自动化检查能否在CI/CD流水线中加入自动化安全扫描步骤对编译产物或部署配置进行检测自动发现此类不安全配置并阻断部署默认安全原则我们的基础设施、容器镜像、部署脚本是否遵循“默认安全”原则即默认配置就是最安全的配置需要更多功能时才手动开启。SpringBoot Actuator未授权访问漏洞像一面镜子映照出应用在便捷性与安全性之间的平衡。便捷的工具用好了是利器用不好就是后门。作为技术人员我们享受框架带来的开发效率提升的同时必须对其潜在的安全风险保持清醒的认识和敬畏。每一次配置的疏忽都可能为攻击者打开一扇门。真正的安全始于每一行谨慎的代码每一次认真的配置审查。
