Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

Шаг 2
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности
close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS‑Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:

  • Промоакции
  • Оповещения
  • Спам

Вебинар: Использование статических анализаторов кода при разработке безопасного ПО - 19.12

>
>
>
Чем опасны уязвимые зависимости в проек…

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

06 Сен 2022

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

0987_PVS-Studio_SCA_ru/image1.png

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

Допустим, у нас есть простейшее веб-приложение, использующее 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 следил за тем, как веб-сервис потребляет ресурсы моей машины:

0987_PVS-Studio_SCA_ru/image2.png

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

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

[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 не являются абсолютной защитой от проблем подобного рода, однако они определённо являются хорошим помощником. Как минимум, искать проблемные компоненты с ними куда проще, чем вручную :).

Популярные статьи по теме


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

Следующие комментарии next comments
close comment form