06.09.2022 17:40
Firensis 0 610 Источник

Современные приложения почти всегда используют сторонние библиотеки. Если библиотека содержит уязвимость, то уязвимым может оказаться и использующее её приложение. Но как определить наличие таких проблемных зависимостей?

Чем опасны уязвимости в компонентах?

Допустим, у нас есть простейшее веб-приложение, использующее RestSharp – достаточно известный клиент для работы с REST API.

Наше приложение принимает какие-то данные в JSON-формате. Для простоты предположим, что обработчик получает строку даты и разбирает её при помощи метода расширения из RestSharp:

[HttpPost]
public IActionResult Index(string jsonDate)
{
  DateTime dateTime = jsonDate.ParseJsonDate(CultureInfo.InvariantCulture);

  // do something

  return View();
}

По идее, самое страшное, что может случиться – получение в jsonDate строки, в которой дата будет записана в некорректном формате. Однако ничего ужасного не произойдёт:

  • в объект dateTime будет записано значение по умолчанию;

  • далее в коде оно как-нибудь по-особому будет обработано;

  • отправитель получит ответ.

Получается, что этот код безопасен?

Ответ зависит от версии библиотеки RestSharp. Если она меньше 106.11.7, то библиотека уязвима к ReDoS атакам (CVE-2021-27293). Но что с того?

Дело в том, что наш обработчик запроса использует функцию ParseJsonDate, которая в свою очередь использует уязвимое регулярное выражение. Следовательно, наше приложение также уязвимо к ReDoS атакам.

Для подтверждения я запустил созданное приложение у себя на компьютере и быстро вручную отправил ему из браузера 10-15 запросов. В качестве JSON-даты я передавал приложению следующую строку:

new Date(000000000000000000000000000000000000000000000000000000000000000000

Одновременно с этим я с помощью Process Hacker следил за тем, как веб-сервис потребляет ресурсы моей машины:

Я бы с радостью отправил ещё десяток запросов, но у меня завис браузер :(.

Давайте вернёмся к коду:

[HttpPost]
public IActionResult Index(string jsonDate)
{
  DateTime dateTime = jsonDate.ParseJsonDate(CultureInfo.InvariantCulture);

  // do something

  return View();
}

Повторюсь, выглядит вполне безобидно, не так ли? Но если подобный код есть в реальном веб-приложении, то его точно так же можно атаковать, перегрузив сервер бессмысленной работой. Конечно, если используется уязвимая версия RestSharp.

Ладно, с RestSharp разобрались — скорее обновляем до последней версии. Теперь приложение в безопасности?

Ну как сказать... Одна зависимость теперь безопасна. А безопасны ли другие?

Как узнать, есть ли у проекта уязвимые компоненты?

Решением задачи поиска проблемных компонентов в приложении занимаются SCA-решения (Software Composition Analysis). Изначально это направление было посвящено поиску компонентов с потенциально проблемными условиями лицензирования, но со временем оно серьёзно расширилось. Сейчас одной из его важнейших составляющих как раз и является поиск уязвимых компонентов.

Если проект зависит от чего-то небезопасного, то SCA-решение может отобразить сообщение по типу следующего:

Referenced package RestSharp 106.11.5 contains vulnerability according to CVE-2021-27293: Incorrect Regular Expression in RestSharp.

Современный рынок предлагает множество решений, производящих анализ зависимостей. Некоторые подобные инструменты также реализуют функционал SAST (статическое тестирование защищённости приложения). Это позволяет искать потенциальные уязвимости к атакам вроде XXE, SQL injection, XSS и т.д. Такое совмещение позволяет одновременно диагностировать наличие проблем и в исходном коде, и в зависимостях.

Если вы программируете на C#, можете попробовать PVS-Studio: анализатор сочетает возможности SAST и SCA. Загрузить триал можно здесь. Чтобы искать дефекты безопасности, включите OWASP-диагностики (уязвимые зависимости ищет диагностика V5625).

Для прочих языков вам могут подойти другие инструменты. Ниже перечислены наиболее популярные из них:

  • Mend (ранее WhiteSource) – мощное решение от компании WhiteSource. Оно позволяет проверять безопасность кода (Mend SAST) и зависимостей (Mend SCA).

  • Black Duck – это один из основных продуктов компании Synopsys. Он ориентирован именно на проверку зависимостей, хотя у этой компании есть и инструмент для статического анализа безопасности – Coverity.

  • Компания Veracode также предоставляет популярные решения для проверки зависимостей и кода на предмет наличия дефектов безопасности: Veracode Static Analysis (SAST) и Veracode Software Composition Analysis (SCA).

Выводы

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

Средства SCA не являются абсолютной защитой от проблем подобного рода, однако они определённо являются хорошим помощником. Как минимум, искать проблемные компоненты с ними куда проще, чем вручную :).

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikita Lipilin. The risks of using vulnerable dependencies in your project, and how SCA helps manage them.

Комментарии (0)