Как разрешить аудит безопасности, обнаруживающий инъекцию журнала в приложении Java Spring Boot
Я пытаюсь получить подробную информацию об исключении, зарегистрировав его с помощью lombok extern Slf4j. Но обнаружил проблему при сканировании покрытия, как показано ниже.
Это результат аудита безопасности. CID 227846 (№1 из 1): внедрение журнала (LOG_INJECTION). Испорченная строка ex сохраняется в журналах. Это может позволить злоумышленнику подделать сообщения журнала, чтобы сбить с толку инструменты автоматического анализа журнала или людей, пытающихся диагностировать атаку или другую проблему. Значение небезопасно используется в байт-коде, который не может быть отображен. Уязвимости, связанные с внедрением журналов, можно устранить, убедившись, что вводимые данные, контролируемые пользователем, соответствуют ожиданиям.
log.error(Constants.EXCEPTION_OCCURRED_MSG, ex);
Я редко находил варианты решения этой проблемы. Подходит ли здесь ESAPI или Apache log4j Audit. Пожалуйста, предложите.
2 ответа
Я не могу много говорить об Apache Log4J Audit, потому что я никогда не смотрел на него (хотя 20-секундное прочтение его главной веб-страницы, похоже, указывает на то, что это скорее попытка структурированных сообщений журнала, которые затем SIEM будут знать, как анализировать, а не какое-либо «безопасное» ведение журнала, которое выполняет фильтрацию/кодирование/и т. д.). Что касается ESAPI, хотя ESAPI в некоторой степени обрабатывает «безопасное ведение журнала», IIRC (не проверял) на самом деле мало что делает с исключениями.. Ведение журнала ESAPI в основном доверяет стеку исключений и больше фокусируется на самом сообщении об ошибке. Как правило, для безопасных проектов пользовательские данные никогда не должны помещаться в сообщения об исключениях, если они не проверены. Но такого рода проверка не может выполняться общей структурой ведения журналов. Для фреймворка ведения журналов он должен быть в состоянии обрабатывать любые
Exception(или, возможно,
Throwable, YMMV) и любую строку, и к тому времени, когда она попадает в структуру ведения журнала, конкретный контекст того, как что-то должно быть проверено, теряется.
«Безопасное ведение журнала» ESAPI в основном состоит из замены символов «\ r» или «\ n» как части регистрируемой строки «сообщения» (не Exception) на «_» (для предотвращения внедрения журнала) и, при необходимости, для кодирования вывода объекта HTML. в сообщении (в случае, если кто-то намеревается просмотреть сообщения журнала в браузере; цель состоит в том, чтобы предотвратить атаки XSS с помощью сообщений журнала). Хотя вы могли бы, приложив достаточные усилия, расширить его, чтобы делать другие вещи (например, отфильтровывать последовательности ESC и т. д.).
В конечном счете, чтобы полностью предотвратить атаки с внедрением журналов, вы должны проверить все ненадежные данные перед их записью в журнал. Валидатор ESAPI может помочь вам в этом, но вам, как разработчику, все равно нужно вызвать его с правильными критериями проверки в нужный момент.
Добавлено 29.12.201 : Что касается использования ESAPI
Validator, я не имел в виду кодирование вывода с помощью ESAPI.
Encoder. Вместо этого вы должны создать регулярное выражение для белого списка ожидаемых данных и поместить его в свой файл validation.properties , а затем вызвать один из
Validator.getValidInput()методы. Если вы не получите
ValidationExceptionброшенный, вывод должен быть «безопасным» в соответствии с вашим регулярным выражением. (Обратите внимание, что вам может понадобиться сделать это в нескольких местах с множеством различных регулярных выражений.) OTOH, я не могу обещать вам, что это сделает ваше сканирование Coverity счастливым, поскольку оно не может знать, является ли регулярное выражение, которое вы предоставляете, правильным или нет. подходящий или нет. (Я также не думаю, что он проведет такой глубокий анализ потока данных, чтобы считать его «безопасным» для использования.)
Я думаю, мне нужно больше подробностей о том, что именно ищет эта ошибка. Например, если проблема заключается в том, что сообщение об исключении, связанное с «ex», содержит PII или другую конфиденциальную информацию, которая может быть зарегистрирована, это намного сложнее, если у вас нет контроля над возникающим исключением. OTOH, если элемент управления вставляется, злоумышленник может вставить что-то вроде эксплойта Log4shell, который атаковал небезопасную десериализацию, которая (очевидно) никто не осознавал, что происходит с 2013 года, это не то, что можно легко защитить, если вообще, потому что проблема находится в базовой системе ведения журнала для подобных вещей. Как правило, лучший способ подойти к этому — поговорить с аудиторами безопасности и задать им конкретные вопросы.что они сочли бы исправлением для этого. Вот какой санитизации или проверки они ожидают? Кроме того, вы должны понимать, что с одобрения руководства вы обычно можете просто где-то зафиксировать риск, а затем решить «принять его». Помогите своему руководству понять, что большинство уязвимостей «внедрения журналов» не настолько серьезны, как то, что мы видели в недавней цепочке уязвимостей Log4J 2. Просто эксплойт Log4Shell в течение последнего месяца или около того держал всех в напряжении. Если вы решите принять риск, вы можете отследить его в чем-то вроде «реестра рисков», который периодически пересматривается, но вы также захотите пометить его в инструменте аудита как «принятый риск».
Боюсь, что, не зная много более конкретных деталей, я не могу дать вам более конкретный ответ. Я готов попытаться предоставить больше помощи на другом форуме, где я могу привлечь своих коллег из ESAPI. В частности, у Джеремайи Стейси, который переписал ESAPI Logger, могут быть некоторые идеи, но я не думаю, что он следит за SO, поэтому электронная почта, вероятно, будет лучшим форумом для начала.
Надеюсь, это немного поможет. -кевин