Bug2Lab — Открытый Spring Boot Actuator без авторизации

Открытый Actuator без авторизации

В проде открыт /actuator/** для всех. Любой человек снаружи может посмотреть конфиг, переменные окружения, health-проверки, а иногда даже скачать heap dump сервиса. Фикс — ограничить доступ и выключить чувствительные эндпоинты наружу.

Как выглядит атака

Атакующий отправляет:
GET /actuator/env
и получает секреты окружения, в том числе доступ к БД.

GET /actuator/env
200 OK (application/json)

{
"spring.datasource.password":"ProdDB_Passw0rd!",
"aws.accessKey":"AKIA...",
"jwt.signing.key":"super-secret-jwt-key"
}

Почему это стало возможным

В приложении Actuator включён полностью (exposure.include=*) и открыт всем без авторизации «на время отладки».

Проблемный код / конфиг
# application.properties
management.endpoints.web.exposure.include=*
management.endpoint.env.show-values=ALWAYS
// SecurityConfig.java
@Bean
SecurityFilterChain filter(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/actuator/**").permitAll() // ❌ открыт наружу
        .anyRequest().authenticated()
    );
    return http.build();
}

Как это чинится правильно

Мы закрываем чувствительные эндпоинты, ограничиваем видимость и требуем роль. Плюс уносим Actuator в отдельный внутренний порт.

Исправленный паттерн
# application-prod.properties
management.endpoints.web.exposure.include=health,info
management.endpoint.env.show-values=NEVER
management.server.port=9001
management.server.address=127.0.0.1  # ✅ только внутри
// SecurityConfig.java
@Bean
SecurityFilterChain filter(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/actuator/**").hasRole("ADMIN") // ✅ не для всех
        .anyRequest().authenticated()
    );
    return http.build();
}

bug2regress Регрессионный тест (стоп-кран)

Скрипт пытается без авторизации сходить в /actuator/env. Если сервер всё ещё отдаёт 200 — билд стопаем. Мы ждём 401 или 403.

#!/bin/bash # actuator-check.sh STATUS=$(curl -s -o /tmp/env.json -w "%{http_code}" \ "https://staging.example.internal/actuator/env") if [ "$STATUS" = "200" ]; then echo "[BLOCK] Actuator/ENV доступен анонимно в стейдже" exit 1 fi echo "[OK] Actuator закрыт извне (HTTP $STATUS)" exit 0

Это фиксирует правило: чувствительные системные эндпоинты не доступны просто так из интернета.

Проверка понимания В чём была проблема?

Любой мог вызвать /actuator/env и увидеть секреты окружения.

Actuator был выставлен наружу с permitAll(), без роли / авторизации.

Проблема была только в отсутствии HTTPS.

Фикс — ограничить список эндпоинтов и закрыть их внутрь / под роль.

Стандарт: Actuator — это не публичная фича для клиента. Это админка. Она должна быть закрыта.

Теория (по желанию) Actuator ≠ «ну просто healthcheck», это админ-панель сервиса

🔎 1. Что такое Actuator?

Spring Boot Actuator — это набор внутренних служебных эндпоинтов: /actuator/health, /actuator/env, /actuator/metrics, /actuator/heapdump и так далее. Они нужны разработчикам и операторам, а не конечным пользователям.

Проблема: многие из них показывают «внутренности» приложения. Не просто «живое / не живое», а прям чувствительные данные.

💣 2. Чем это опасно бизнесу?

Можно вытащить пароли к продовой БД / очередям / внешним API.
Можно узнать внутренние имена хостов, сервисов, портов (карта инфраструктуры).
Можно выкачать heap dump процесса и дальше выцепить токены и ключи прямо из памяти.

То есть это не просто «знаем, что у вас Java 17». Это «знаем ваши секреты, можем входить в соседние сервисы под вами».

🧪 3. Почему это вообще оказалось в проде?

«Надо было быстро посмотреть метрики, я временно включил `permitAll()`».
«Мы на стейдже так делали и просто скопировали конфиг в прод».
«Это же только для devops, никто снаружи не найдёт URL» — нашли.

Это классика: отладочная конфигурация случайно стала боевой.

📏 4. Новый стандарт команды

Actuator живёт только на внутреннем интерфейсе/порте (127.0.0.1 или внутри k8s-сети).
Чувствительные эндпоинты (/env, /heapdump, /threaddump) не торчат наружу боевого кластера.
Если что-то всё-таки проброшено наружу (например, /health для балансировщика) — оно проходит через auth/роль.

То есть актор теперь не может просто открыть браузер и посмотреть ваши секреты.

🚦 5. Зачем регресс-тест в пайплайне?

Сегодня вы закрыли /actuator/env, а завтра кто-то открыл его снова «для удобства диагностики инцидента». Регрессионный тест шлёт анонимный запрос. Если видит 200 — билд стопается. Это уже технический контроль, а не «надеемся, что никто не включит обратно».

✅ 6. Что можно честно сказать руководству

Да, раньше внутренние админ-эндпоинты были доступны извне.
Теперь доступ ограничен по роли и вынесен во внутренний контур.
Мы поставили в пайплайн автоматическую проверку, которая не даст снова выпустить сервис с открытым Actuator.

Это превращает «инцидент с утечкой секретов» в «контролируемый процесс с техгарантией».

bug2regress Регрессионный тест (стоп-кран)

Проверка понимания В чём была проблема?

Теория (по желанию) Actuator ≠ «ну просто healthcheck», это админ-панель сервиса раскрыть

Теория (по желанию) Actuator ≠ «ну просто healthcheck», это админ-панель сервиса