# Чем опасны уязвимые зависимости в проекте и как с этим помогает SCA?

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

![0987_PVS-Studio_SCA_ru/image1.png](https://import.viva64.com/docx/blog/0987_PVS-Studio_SCA_ru/image1.png)

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

Допустим, у нас есть простейшее веб\-приложение, использующее [RestSharp](https://restsharp.dev/) – достаточно известный клиент для работы с REST API\.

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

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

  // do something

  return View();
}
```

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

* в объект _dateTime_ будет записано значение по умолчанию;
* далее в коде оно как\-нибудь по\-особому будет обработано;
* отправитель получит ответ\.

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

Ответ зависит от версии библиотеки RestSharp\. Если она меньше 106\.11\.7, то библиотека уязвима к [ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) атакам \([CVE\-2021\-27293](https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-27293)\)\. Но что с того?

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

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

```cpp
new Date(000000000000000000000000000000000000000000000000000000000000000000
```

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

![0987_PVS-Studio_SCA_ru/image2.png](https://import.viva64.com/docx/blog/0987_PVS-Studio_SCA_ru/image2.png)

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

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

```cpp
[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\. Загрузить триал можно [здесь](https://pvs-studio.ru/ru/pvs-studio/try-free/)\. Чтобы искать дефекты безопасности, [включите](https://pvs-studio.ru/ru/docs/manual/6536/) OWASP\-диагностики \(уязвимые зависимости ищет диагностика V5625\)\.

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

* [Mend](https://www.mend.io/) \(ранее WhiteSource\) – мощное решение от компании WhiteSource\. Оно позволяет проверять безопасность кода \(Mend SAST\) и зависимостей \(Mend SCA\)\.
* [Black Duck](https://www.synopsys.com/software-integrity/security-testing/software-composition-analysis.html) – это один из основных продуктов компании Synopsys\. Он ориентирован именно на проверку зависимостей, хотя у этой компании есть и инструмент для статического анализа безопасности – Coverity\.
* Компания [Veracode](https://www.veracode.com/) также предоставляет популярные решения для проверки зависимостей и кода на предмет наличия дефектов безопасности: Veracode Static Analysis \(SAST\) и Veracode Software Composition Analysis \(SCA\)\.

## Выводы

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

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