Spring Boot Actuator安全配置与信息泄露防护-代码聚汇网

Spring Boot Actuator安全配置与信息泄露防护

抹茶柚子冰

1. Spring Boot Actuator信息泄露风险深度解析

作为Java开发者，我们都习惯使用Spring Boot Actuator来监控应用状态，但很多人可能没意识到，一个简单的配置失误就可能让敏感数据完全暴露。去年我在审计某金融系统时，就发现因Actuator配置不当导致数据库凭证泄露的典型案例。让我们从攻击者视角看看这些漏洞的严重性。

1.1 端点暴露的安全隐患

问题通常始于application.properties中的这行配置：

properties复制management.endpoints.web.exposure.include=*

这相当于把家里所有房门钥匙都挂在门口。Actuator默认提供13个监控端点，包括：

/env：完整环境变量（含数据库密码）
/heapdump：JVM内存快照（可提取敏感数据）
/mappings：所有Controller路由信息
/prometheus：应用性能指标数据

我曾用Postman测试过某企业的测试环境，通过/env直接获取到：

json复制{
  "spring.datasource.password": {
    "value": "Jdbc#1234",
    "origin": "class path resource [application.yml]:15:20"
  }
}

这种明文密码配合内网SSH密钥泄露，攻击者可以长驱直入。

1.2 生产环境正确配置方案

安全配置应该遵循最小权限原则：

properties复制# 只开放健康检查端点
management.endpoints.web.exposure.include=health,info

# 强制开启认证
management.endpoint.health.roles=ACTUATOR
management.security.enabled=true

# IP白名单限制
management.server.address=127.0.0.1

如果是Spring Boot 2.3+版本，更推荐：

yaml复制management:
  endpoint:
    health:
      show-details: when_authorized
  endpoints:
    web:
      exposure:
        include: health
      base-path: /internal-monitor

关键提示：永远不要在application-dev.properties中配置生产数据库连接，我见过太多开发者忘记切换配置导致生产库密码泄露的案例。

1.3 敏感信息防护实践

对于必须暴露的端点，建议增加以下防护层：

使用Spring Security进行端点鉴权

java复制@Configuration
public class ActuatorSecurity extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.requestMatcher(EndpointRequest.toAnyEndpoint())
            .authorizeRequests().anyRequest().hasRole("ACTUATOR")
            .and().httpBasic();
    }
}

对环境变量进行脱敏处理

java复制@Configuration
public class EnvSanitizer implements EnvironmentPostProcessor {
    @Override
    public void postProcessEnvironment(ConfigurableEnvironment env, 
                                     SpringApplication app) {
        env.getPropertySources().addFirst(
            new SanitizingPropertySource(env.getPropertySources())
        );
    }
}

定期使用OWASP ZAP扫描Actuator端点

2. Swagger接口文档的安全陷阱

2.1 自动化文档的双刃剑

Swagger UI确实方便，但默认配置下/swagger-ui.html会暴露：

所有API接口路径
参数结构
甚至可以直接发起测试请求

某次渗透测试中，我通过/v2/api-docs发现了未授权支付的API：

json复制{
  "/api/payment": {
    "post": {
      "tags": ["payment"],
      "operationId": "createPayment",
      "parameters": [
        {"name": "amount", "in": "body"}
      ]
    }
  }
}

攻击者可以轻易构造伪造请求。

2.2 生产环境禁用策略

必须区分开发和生产配置：

properties复制# application-prod.properties
springfox.documentation.swagger-ui.enabled=false
springfox.documentation.enabled=false

更安全的做法是使用Spring Profile控制：

java复制@Profile("!prod")
@Configuration
@EnableSwagger2
public class SwaggerConfig {
    // 开发环境配置
}

2.3 接口文档的替代方案

对于必须提供的API文档，建议：

使用Redoc替代Swagger UI
部署独立的文档服务器
添加JWT认证中间件
记录文档访问日志

我曾帮某电商平台实施这样的方案：

code复制/docs
├── redoc.html
└── auth
    ├── login
    └── verify?token=xxx

3. Druid监控控制台的认证绕过

3.1 默认密码的致命风险

Druid的监控页面/druid/login.html常见问题：

properties复制spring.datasource.druid.stat-view-servlet.login-username=admin
spring.datasource.druid.stat-view-servlet.login-password=admin

这种默认配置等于敞开大门。

3.2 加固方案实施步骤

强制修改复杂密码

properties复制spring.datasource.druid.stat-view-servlet.login-username=monitor_admin
spring.datasource.druid.stat-view-servlet.login-password=7s#dF!k9*Lp

限制访问IP范围

properties复制spring.datasource.druid.stat-view-servlet.allow=192.168.1.100,10.0.0.50

添加二次认证

java复制@Controller
@RequestMapping("/druid")
public class DruidSecurityController {
    @GetMapping("/**")
    public String checkAuth(@RequestParam String token) {
        if(!jwtUtil.validate(token)) {
            throw new AccessDeniedException();
        }
        // 转发到真实Druid页面
    }
}

3.3 监控数据保护技巧

定期清理SQL监控记录
敏感表名进行模糊处理
关闭WebStatFilter的session监控

properties复制spring.datasource.druid.web-stat-filter.enabled=false

4. 开发与生产环境的配置隔离

4.1 环境标识泄露的连锁反应

通过/env端点泄露的dev标识会暴露：

调试模式开启
未压缩的静态资源
详细的错误堆栈
宽松的安全策略

我曾利用某系统的dev模式特性，通过修改H2数据库配置获取了管理员权限。

4.2 多环境配置管理规范

严格的profile隔离

code复制src/main/resources/
├── application.yml
├── application-dev.yml
├── application-test.yml
└── application-prod.yml

敏感配置加密处理

yaml复制spring:
  datasource:
    password: '{cipher}FKSAJDFGYOS8F7GLHAKERGFHLSAJ'

使用Vault或KMS管理密钥

4.3 构建过程中的防护

在Maven构建时过滤资源：

xml复制<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>true</filtering>
            <excludes>
                <exclude>application-prod.yml</exclude>
            </excludes>
        </resource>
    </resources>
</build>

5. 应急响应与持续监控

5.1 信息泄露事件处理流程

立即下线受影响服务
轮换所有泄露的凭据
分析访问日志定位攻击路径
更新WAF规则阻断扫描请求

5.2 安全审计工具推荐

OWASP ZAP：自动化扫描Actuator端点
GitGuardian：检测代码中的敏感信息
TruffleHog：搜索git历史中的密码
Semgrep：静态分析配置风险

5.3 监控指标设置建议

在Prometheus中配置以下告警规则：

yaml复制groups:
- name: info_leak
  rules:
  - alert: ActuatorAccess
    expr: rate(http_server_requests_seconds_count{uri=~"/actuator/.*"}[5m]) > 10
    labels:
      severity: critical

记得去年处理过某次事故后，我们团队养成了每周用下面命令检查配置的习惯：

bash复制grep -r "management.endpoints" src/ | grep -v "include=health"

这些经验教训让我明白，安全不是功能开关，而是贯穿开发全流程的实践。每次提交代码前，不妨多问一句：这个配置会不会在运维手册里变成漏洞报告？