Оглавление
V5319. OWASP. Possible log injection. Potentially tainted data is written into logs.
Анализатор обнаружил логирование данных из внешнего источника без предварительной проверки. Это может нарушить процессы логирования или скомпрометировать содержание логов.
Ошибки, связанные с логированием данных, могут быть отнесены к следующей категории OWASP Top 10 Application Security Risks:
- A09:2021 – Security Logging and Monitoring Failures.
Если логирование пользовательского ввода производится без проверок, то злоумышленник может внедрить произвольные данные в лог.
Предположим, что логи хранятся в простом текстовом формате. Узнать формат хранения логов можно разными способами. Например, если проект имеет открытый исходный код или с помощью какой-либо другой атаки. Возможный лог может иметь такой вид:
INFO: User 'SomeUser' entered value: '2022'.
INFO: User 'SomeUser' logged out.
Код, осуществляющий логирование, может выглядеть так:
public class InputHelper {
private final Logger logger = LoggerFactory.getLogger(InputHelper.class);
private String username;
public void process(InputStream stream) {
Scanner scanner = new Scanner(stream);
String userInput = scanner.next();
String logMessage = "User '" + userName +
"' entered value: '" + userInput + "'.";
logger.info(logMessage); // <=
}
}В таком случае злоумышленник может внедрить произвольные данные о событиях, которые никогда не происходили.
Например, злоумышленник вводит такой текст:
2022/r/nINFO: User 'Admin' logged out.
Тогда в логах появится такая запись, которая может ввести в заблуждение человека, анализирующего логи:
INFO: User 'SomeUser' entered value: '2022'.
INFO: User 'Admin' logged out.
Рассмотрим другой вид атаки: если логи хранятся в формате XML, злоумышленник может внедрить данные, которые сделают содержимое отчёта некорректным. Также последующий процесс парсинга готовых логов может выдать неправильные данные или завершиться ошибкой.
Злоумышленник может внедрить незакрытый тег и сделать невозможным парсинг XML-файла.
Список возможных уязвимостей зависит от архитектуры и настроек ввода, логгера, вывода логов или иных частей системы логирования. Например, атака на XML-логи может иметь следующие последствия:
- нарушение процесса добавления новых записей в логи;
- нарушение процесса просмотра готовых логов;
- эксплуатация XEE-уязвимости;
- эксплуатация XXE-уязвимости;
- эксплуатация уязвимости небезопасной десериализации.
Некоторых атак можно избежать экранированием символов, чтобы они не рассматривались как часть XML-синтаксиса. Например, начальный символ тега < следует экранировать как <. Выполнить экранирование XML-лога можно следующим образом:
import org.apache.commons.text.StringEscapeUtils;
public class EscapedInputHelper {
private final Logger logger =
LoggerFactory.getLogger(EscapedInputHelper.class);
private String username;
public void process(InputStream stream) {
Scanner scanner = new Scanner(stream);
String userInput = scanner.next();
String escapedInput = StringEscapeUtils.escapeXml11(userInput);
String logMessage = "User '" + userName +
"' entered value: '" + escapedInput + "'.";
logger.info(logMessage);
}
}Ещё один пример: стандарт JSON запрещает наличие null-символов (\0) в файлах. Если злоумышленник использует этот символ, это может сломать процесс сохранения или просмотра готовых логов. Поэтому null-символ следует экранировать как \u0000.
Другой пример: если логи хранятся в реляционной СУБД, использующей SQL, отсутствие проверок входных данных может привести к SQL-инъекции (подробнее см. диагностическое правило V5309).
Была ли полезна эта страница документации?
