Анализатор обнаружил логирование данных из внешнего источника без предварительной проверки. Это может нарушить процессы логирования или скомпрометировать содержание логов.
Ошибки, связанные с логированием данных, могут быть отнесены к следующей категории OWASP Top 10 Application Security Risks:
Если логирование пользовательского ввода производится без проверок, то злоумышленник может внедрить произвольные данные в лог.
Предположим, что логи хранятся в простом текстовом формате. Узнать формат хранения логов можно разными способами. Например, если проект имеет открытый исходный код или с помощью какой-либо другой атаки. Возможный лог может иметь такой вид:
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-логи может иметь следующие последствия:
Некоторых атак можно избежать экранированием символов, чтобы они не рассматривались как часть 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).