Обеззараженный регистратор CloudLoggerFactory демонстрирует уязвимость CRLF-инъекции в Veracode Scan - PullRequest
Новая
       5

Обеззараженный регистратор CloudLoggerFactory демонстрирует уязвимость CRLF-инъекции в Veracode Scan

0 голосов
/ 20 февраля 2019

Мы используем CloudLoggerFactory S4 SDK для регистрации исключений в нашем приложении.Для класса «SampleClass» мы создаем регистратор, подобный следующему: 

private static final Logger logger = CloudLoggerFactory.getSanitizedLogger(SampleClass.class, "(END)");

, и вызываем его для исключения e: 

    logger.error(e.getMessage(), e);

Сканирование Veracode показало, что эта строка регистрации имеет видуязвимы для инъекций CLRF.Насколько я понимаю, getSanitizedLogger в сочетании с аргументом "(END)" должен решить эту проблему.Можете ли вы дать некоторое представление об этом вопросе, пожалуйста?

Заранее спасибо!

Ответы [ 2 ]

0 голосов
/ 12 июля 2019

На самом деле мы планируем удалить функцию очистки журналов в следующем основном выпуске.

Мы пришли к выводу, что на самом деле это дает ложное чувство безопасности и что его следует учитывать на уровне реализации регистраторавместо этого, что мы не можем сделать на уровне SDK, поскольку полагаемся только на абстракцию Slf4j.

(Отказ от ответственности: я один из разработчиков SAP Cloud SDK.)

0 голосов
/ 20 февраля 2019

То, что должен делать продезинфицированный регистратор, делает идентификацию подделки журналов.Чтобы разрешить это, он делает следующее:

  • Этот регистратор имеет ваш предоставленный класс (SampleClass.class в вашем случае) в качестве имени регистратора.Это имя будет помещено в вывод на печать в зависимости от конфигурации вашей реализации регистратора.Это поведение по умолчанию SLF4J.

  • Добавить (END OF LOG ENTRY) (или предоставленный токен) в конце каждого сообщения журнала, созданного этим регистратором.Если этот токен встречается в вашем лог-сообщении, он заменяется на (MESSAGE MIGHT BE FORGED!), так как это будет индикатором того, что некоторые входные данные пытались подделать ваши лог-сообщения.

Оба эти свойствапозволяют определить, является ли сообщение журнала действительным или было создано с помощью журнала Forging.

Чтобы увидеть это, взгляните на следующий пример, сначала с «неанизированным» логгером: 

final Logger logger = CloudLoggerFactory.getLogger(SampleClass.class);

logger.error("Some valid first message");
logger.info("Something still valid\n[main] ERROR very.important.class Major Database Error!");
logger.error("Some valid last message");

На моей машине вывод этого выглядит как 

[main] ERROR com.sap.sandbox.SampleClass - Some valid first message
[main] INFO com.sap.sandbox.SampleClass - Something still valid
[main] ERROR very.important.class Major Database Error!
[main] ERROR com.sap.sandbox.SampleClass - Some valid last message

Таким образом, нет никакой возможности определить, что что-то не так с этими сообщениями.

Поэтому, если вы используете CloudLoggerFactory.getSanitizedLogger вместо CloudLoggerFactory.getLogger, вы получите следующий вывод журнала: 

[main] ERROR com.sap.sandbox.SampleClass - Some valid first message (END OF LOG ENTRY)
[main] INFO com.sap.sandbox.SampleClass - Something still valid
[main] ERROR very.important.class Major Database Error! (END OF LOG ENTRY)
[main] ERROR com.sap.sandbox.SampleClass - Some valid last message (END OF LOG ENTRY)

Здесь вы можете видеть, что одно из сообщений из SampleClass, которое должно фактически заканчиваться токеном, заканчивается без него.Поэтому вы можете сделать вывод, что в журнале есть какая-то ошибка, и вам нужно исследовать эту проблему более подробно.

Так много для аспекта «Подделка журналов», который представляет собой фактическую атаку, которую распознаваемый регистратор делает идентифицируемой.

Относительно проблемы внедрения CLRF: Эта проблема в значительной степени зависит от дальнейшего использования созданного вывода журнала:

  • Если вы храните сообщения журнала в базе данных, должен быть какой-то способ предотвратить внедрение SQL.
  • Если вы просматриваете файлы журналов с помощью веб-анализатора журналов, должен быть какой-то способ предотвратить XSS.
  • ...

Если мыисключил бы все эти потенциальные варианты использования, это фактически сделало бы простое чтение файлов журнала с помощью редактора, который, по моему мнению, является наиболее распространенным вариантом использования, гораздо более сложным.

Так что вам нужно будет решить, подходит ли для вашего случаяэто актуальная проблема или просто ложный положительный результат.

Еще один момент заключается в том, что все ваши другие зависимости должны будут выходить из своего журнала.сообщения для вашего варианта использования.Это означает, что более простым и всеобъемлющим решением было бы настроить его в реальной реализации регистратора, например, для Logback: https://logback.qos.ch/manual/layouts.html#replace.

...