English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

гость
1 / ?
назад к урокам

Заголовки как «мешок»

HTTP-логирующие фреймворки обрабатывают заголовки запроса как мешок пар ключ-значение. API логирования отдаёт весь мешок целиком. Операторы включают логирование заголовков для отладки: когда запрос падает, заголовки рассказывают историю. Нет встроенного denylist. Нет фильтрации учётных данных в документации. Полные заголовки — на диск.

Учётные заголовки в типичном запросе:

- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (JWT или OAuth-токен)

- Cookie: session=abc123; auth=xyz789

- X-API-Key: sk-live-abc123...

- X-Auth-Token: ghp_abc123... (персональный токен доступа GitHub)

Эти значения аутентифицируют запрос. Будучи записанными в лог-файл, они позволяют аутентифицировать любой запрос.

Конвейер учётных данных

Учётные данные, записанные в лог-файл, не остаются на месте. Они перемещаются:

1. Веб-сервер пишет в /var/log/nginx/access.log

2. Агент ротации логов (logrotate) копирует в /var/log/nginx/access.log.1

3. Агент доставки логов (Fluentd, Filebeat, Logstash) читает и отправляет в агрегатор

4. Агрегатор логов (Elasticsearch, Splunk, Datadog) индексирует и хранит

5. Хранится 30–90 дней по умолчанию

Учётные данные существуют одновременно во всех пяти местах. Отзыв токена сессии не удаляет учётные данные из агрегатора логов. Они остаются доступными для поиска, экспорта и просмотра любым пользователем с доступом к логам в течение всего периода хранения.

Окно экспозиции

Окно экспозиции учётных данных в памяти: max(длительность сессии, время жизни процесса). Сессия: часы–дни. Процесс: часы–недели.

Окно экспозиции учётных данных в логах: max(длительность сессии, срок хранения логов). Сессия: часы–дни. Хранение: 30–90 дней.

Для кражи учётных данных из памяти злоумышленнику нужно присутствовать в течение окна сессии. Для кражи учётных данных из логов достаточно доступа к агрегатору логов — это можно сделать задним числом в течение всего периода хранения.

MOAD-0003 vs MOAD-0004

MOAD-0003 (Утечка в памяти): учетные данные в памяти попадают в неправильный обработчик запроса. Доступны только в течение времени жизни процесса через пул потоков. Эфемерные.

MOAD-0004 (Секрет в логах): учетные данные на диске сохраняются после ротации, пересылки и агрегации логов. Доступны ретроспективно любому, у кого есть доступ к логам, в течение 30–90 дней. Постоянные.

Структурное различие: эфемерные vs постоянные. Исправление работает на другом уровне.

Эфемерные vs Постоянные

Различие между эфемерными и постоянными определяет поверхность риска, уровень исправления и требования к реагированию на инциденты.

Почему MOAD-0004 несёт более высокий риск, чем MOAD-0003? Сравните, где и как долго хранится каждая учетная запись.

Denylist учётных данных на уровне сериализации

Решение: denylist учётных данных на уровне сериализации. Перед тем как любое значение заголовка попадёт в лог, проверяйте имя заголовка по denylist. Заменяйте значение на [REDACTED].

CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}

def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}

Denylist должен находиться на уровне сериализации, а не на уровне запроса логов. Редактирование на уровне запроса логов: применяется после того, как учётные данные попали на диск; исходное значение всё ещё существует, просто скрыто от отображения. Редактирование на уровне сериализации: учётные данные никогда не попадают на диск. Исходное значение никогда не попадает в лог-файл, log shipper или log aggregator.

Тестирование Denylist

Три тестовых сценария:

- Positive: запрос с Authorization: Bearer token123 создаёт запись в логе с Authorization: [REDACTED]

- Отрицательный: запрос с Content-Type: application/json создаёт запись в логе со значением без изменений

- Без учёта регистра: AUTHORIZATION: Bearer token123 также приводит к [REDACTED] (имена HTTP-заголовков нечувствительны к регистру)

Denylist требует поддержки: новые шаблоны заголовков учётных данных (например, пользовательские заголовки X-Service-Auth) нужно добавлять явно. Исправление структурное, но не самоподдерживающееся.

Применить Denylist

Команда настраивает формат access-лога Nginx, чтобы включить все заголовки запроса для отладки инцидента в продакшене. Конфигурация:

log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;

Они устраняют инцидент и планируют удалить отладочную конфигурацию, но изменение не попадает в продакшен до следующего цикла деплоя (через 7 дней).

Определите дефект. Какие заголовки с учётными данными могут быть раскрыты? Опишите подход с denylist: где он применяется, что проверяет и что возвращает?