Зачем использовать SCA?
Добрый день! Меня зовут Дмитрий Сигаев и в этом блоге я делюсь своим опытом в разработки высоконагруженных системах.
Хорошая высоконагруженная система должна быть безопастной и уствойчивой к атакам. Поэтому сегодня мы продолжаем говорить о анализе состава программного обеспечения (Software Composition Analysis - сокр. SVA).
Это методология анализа компонентов приложений. Анализ позволяет обнаружить уязвимые компоненты, слабые места безопасности или проблемы лицензирования.
Большинство современных приложений используют сторонние библиотеки. Если такая библиотека содержит уязвимость, то приложение, использующее эту библиотеку, также может быть уязвимым. Но как можно выявить такие проблемные зависимости?
Опасности уязвимых компонентов
Предположим, у нас есть простое веб-приложение, использующее RestSharp , довольно известную клиентскую библиотеку REST API для .NET.
Наше приложение получает некоторые данные в формате JSON. Давайте немного упростим это и представим, что обработчик получает строку даты и анализирует ее с помощью метода расширения RestSharp:
1 | [HttpPost] |
Кажется, самое худшее, что может случиться — строка в jsonDate будет иметь неправильный формат даты. Однако вот что произойдет:
- объект dateTime получит значение по умолчанию;
- то значение будет обработано определенным образом;
- отправитель получит ответ.
Итак, безопасен ли этот код?
Это зависит от версии библиотеки RestSharp. Если версия ниже 106.11.7, библиотека уязвима для атак ReDoS ( CVE-2021-27293 ). Ну и что? Что из этого всего получается?
Дело в том, что наш обработчик запросов использует функцию ParseJsonDate , которая использует уязвимое регулярное выражение. Следовательно, наше приложение также уязвимо для атак ReDoS .
Чтобы убедиться, что наше приложение уязвимо, я отправил своему приложению 10-15 запросов из браузера за раз. Я передал следующую строку в качестве даты JSON в свое приложение:
1 | new Date(000000000000000000000000000000000000000000000000000000000000000000 |
В то же время я использовал Process Hacker для мониторинга того, как веб-служба потребляет мои системные ресурсы:
Я бы хотел отправить еще десяток запросов, но мой браузер завис :(.
Вернемся к коду:
1 | [HttpPost] |
Выглядит довольно безобидно, не правда ли? Но если реальное веб-приложение имеет подобный код, оно может быть атаковано и привести к перегрузке сервера (при условии использования уязвимой версии RestSharp).
Ладно, с RestSharp все понятно. Нужно просто обновить его до последней версии. И приложение безопасно, да?
Не совсем… Только одна зависимость безопасна. А как насчет других?
Способы проверки проекта на наличие уязвимых компонентов
SCA (Software Composition Analysis) — инструмент, который выявляет уязвимости программного обеспечения с открытым исходным кодом. Изначально SCA использовался для управления рисками соответствия лицензии, но со временем продукт был масштабирован. И теперь одной из его основных функций является обнаружение уязвимых компонентов.
Если проект зависит от чего-то небезопасного, решение SCA выдает следующее сообщение:
Указанный пакет RestSharp 106.11.5 содержит уязвимость согласно CVE-2021-27293: Некорректное регулярное выражение в RestSharp.
Сегодня у нас есть различные инструменты для анализа зависимостей, например KuberSCA. Некоторые инструменты также интегрируют SAST (статическое тестирование безопасности приложений). Это позволяет вам искать потенциальные уязвимости, которые могут привести к атакам типа XXE, SQL-инъекции, XSS и т. д. Если вы интегрируете и SAST, и SCA, вы сможете диагностировать проблемы как в исходном коде, так и в зависимостях.
Заключение
Любое приложение может быть уязвимым, даже если его код корректен. Уязвимые зависимости иногда трудно найти. Таким образом, риски действительно высоки, поскольку такие зависимости могут сильно повлиять на работу приложения.
Инструменты SCA не идеальны — они не могут сделать ваш код на 100% безопасным. Однако они определенно помогают обнаружить уязвимые компоненты. Более того, вам не придется делать это вручную :).