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 personal access token pattern)

Ці значення автентифікують запит. Записані у файл журналу, вони дозволяють автентифікувати будь-який запит.

Конвеєр облікових даних

Облікові дані, записані у файл журналу, не залишаються на одному місці. Вони подорожують:

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? Порівняйте, де саме перебуває кожна облікова інформація та скільки часу вона зберігається.

Список заборони облікових даних на рівні серіалізації

Виправлення: список заборони облікових даних на рівні серіалізації. Перш ніж будь-яке значення заголовка потрапить у вивід журналу, перевірте назву заголовка за списком заборони. Замініть значення на [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()
}

Денайліст належить до шару серіалізації, а не до шару запиту логів. Редактування запиту логів: застосовується після того, як облікові дані потрапили на диск; необроблене значення все ще існує, просто приховане від перегляду. Редактування шару серіалізації: облікові дані ніколи не потрапляють на диск. Необроблене значення ніколи не потрапляє до файлу логів, лог-шипера чи агрегатора логів.

Тестування денайліста

Три тестові патерни:

- Позитивний: запит з Authorization: Bearer token123 створює запис у логах з Authorization: [REDACTED]

- Негативний: запит із Content-Type: application/json створює запис у журналі зі збереженим значенням

- Незалежно від регістру: AUTHORIZATION: Bearer token123 також створює [REDACTED] (назви HTTP-заголовків не залежать від регістру)

Список заборонених слів потребує обслуговування: нові шаблони заголовків облікових даних (наприклад, власні заголовки X-Service-Auth) потребують явного додавання. Виправлення є структурним, але не самопідтримувальним.

Застосувати список заборонених слів

Команда налаштовує формат журналу доступу Nginx для включення всіх заголовків запиту з метою налагодження інциденту у продакшені. Конфігурація:

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

Вони усувають інцидент і планують видалити налаштування налагодження, але зміна не потрапляє у продакшн до наступного циклу розгортання (через 7 днів).

Визначте дефект. Які заголовки з обліковими даними можуть бути розкриті? Опишіть підхід з denylist: де він застосовується, що перевіряє та що видає?