Современные приложения почти всегда используют сторонние библиотеки. Если библиотека содержит уязвимость, то уязвимым может оказаться и использующее её приложение. Но как определить наличие таких проблемных зависимостей?
Чем опасны уязвимости в компонентах?
Допустим, у нас есть простейшее веб-приложение, использующее 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.
