Сервис записывает пользовательское значение в журнал событий. Как проверить, позволяет ли это значение подделать отдельную запись журнала?
Нужно передать в контролируемое поле последовательности перевода строки и проверить необработанный журнал, систему агрегации и интерфейс просмотра. Уязвимость есть, если введённое значение разбивается на несколько событий или позволяет визуально создать запись с ложным уровнем, временем либо сообщением.
Защита должна обеспечивать безопасное представление пользовательских данных: например, структурированное журналирование с корректным экранированием управляющих символов и однозначным отделением полей от содержимого.
Журналы первоначально создавались как последовательности текстовых строк, удобные для чтения человеком и обработки простыми утилитами. Когда в такие строки начали попадать данные HTTP-запросов, имена пользователей и сообщения об ошибках, пользовательский ввод стал влиять на структуру журнала.
Проблема получила известность как инъекция в журналы или подделка записей журнала. Она особенно опасна для систем, где сотрудники расследуют инциденты по текстовым журналам или автоматические средства реагирования принимают решения по их содержимому.
Если приложение без безопасного форматирования записывает пользовательскую строку в многострочный журнал, символы перевода строки могут завершить текущую запись и начать следующую. Злоумышленник способен добавить ложное сообщение, скрыть связь события с исходным запросом или нарушить работу парсера.
Последствия включают искажение аудита, затруднение расследования, ложные срабатывания или пропуск атак системой мониторинга. Это не обязательно даёт выполнение кода: основной риск состоит в потере достоверности и целостности журналов.
Тест следует проводить в несколько этапов. Сначала нужно определить все поля, попадающие в журналы: имя пользователя, параметры запроса, заголовки, идентификаторы объектов, сообщения об ошибках и значения, передаваемые во внешние системы журналирования.
Затем в каждое поле подставляют управляющие символы, прежде всего варианты перевода строки, а также последовательности, значимые для используемого формата. Проверять нужно не только ответ приложения, но и исходный файл или поток журнала, промежуточный сборщик, хранилище и конечную панель мониторинга: на каждом этапе данные могут интерпретироваться по-разному.
Безопасный результат — пользовательское значение остаётся одним полем одной записи, а управляющие символы отображаются как данные либо надёжно экранируются. Структурированное журналирование снижает риск, поскольку сообщение и его поля передаются отдельно, однако оно не отменяет проверку: последующий экспорт в текстовый формат или визуализатор может снова создать проблему.
Нужно также убедиться, что в журналы не попадают секреты: пароли, токены доступа и полные значения cookies. Экранирование защищает структуру записи, но не устраняет риск утечки чувствительных данных.
Сервис журналировал причину отказа во входе вместе с именем пользователя. При проверке обычного имени проблем не было, но значение с переводом строки отображалось в системе мониторинга как две записи: реальная ошибка и добавленное пользователем сообщение о якобы успешной административной операции.
Рассматривались два варианта. Простое удаление переводов строки было легко внедрить, но могло изменить смысл легитимного текста и не учитывало другие разделители формата. Переход на структурированные события требовал изменений в сборщике и правилах мониторинга, зато сохранял границы полей и позволял единообразно обрабатывать значения.
Выбрали структурированные события с явным экранированием при текстовом экспорте и отдельным тестом для панели мониторинга. После исправления ввод оставался частью одной записи на всех этапах, а правила обнаружения атак перестали зависеть от визуального вида пользовательского текста.
1. Достаточно ли удалить символ перевода строки?
Нет. Надёжность такого фильтра зависит от формата журнала, платформы и всех промежуточных преобразований. Кроме перевода строки, значение может содержать другие управляющие символы или специальные разделители, а последующий компонент может декодировать их после фильтрации. Предпочтительнее отделять данные от структуры записи с помощью структурированного формата и проверять весь путь до конечного потребителя.
2. Безопасно ли структурированное журналирование автоматически?
Нет. Оно защищает только при условии, что библиотека действительно сериализует поля как данные, а не конкатенирует их в готовую строку. Риск может появиться при экспорте в обычный текст, преобразовании в CSV, отображении в веб-интерфейсе или передаче в систему, использующую собственный парсер. Поэтому тестировать нужно не только место формирования события, но и места его преобразования и отображения.
3. Как отличить подделку записи журнала от обычного многострочного сообщения об ошибке?
Нужно анализировать структуру события, а не только внешний вид текста. У каждой записи должны сохраняться однозначные метаданные: время, идентификатор события, источник, идентификатор запроса и отдельные поля сообщения. Если пользовательское значение может создать новую запись с независимыми метаданными или изменить интерпретацию исходного события, это подделка; если оно лишь отображается внутри одного корректно сериализованного поля, уязвимость не подтверждается.