Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

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

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

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

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

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


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

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

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

Популярные статьи по теме
Атака Trojan Source: скрытые уязвимости

Дата: 15 Апр 2022

Автор: Гость

Мы представляем новый тип атаки для внедрения в исходный код вредоносных изменений, по-разному выглядящих для компилятора и человека. Такая атака эксплуатирует тонкости стандартов кодирования символо…
Почему моё приложение при открытии SVG-файла отправляет сетевые запросы?

Дата: 18 Фев 2022

Автор: Сергей Васильев

Вы решили сделать приложение, работающее с SVG. Набрали библиотек, запаслись энтузиазмом, и в итоге всё удалось. Но вот незадача! Внезапно вы обнаруживаете, что приложение отправляет странные сетевые…
Уязвимости из-за обработки XML-файлов: XXE в C# приложениях в теории и на практике

Дата: 11 Фев 2022

Автор: Сергей Васильев

Как простая обработка XML-файлов может стать дефектом безопасности? Каким образом блог, развёрнутый на вашей машине, может стать причиной утечки данных? Сегодня мы ответим на эти вопросы и разберём, …
OWASP Top Ten и Software Composition Analysis (SCA)

Дата: 22 Окт 2021

Автор: Никита Липилин

Категория A9 из OWASP Top Ten 2017 (ставшая A6 в OWASP Top Ten 2021) посвящена использованию компонентов с известными уязвимостями. Для её покрытия в PVS-Studio разработчикам придётся превратить анал…
Как Visual Studio 2022 съела 100 Гб памяти и при чём здесь XML бомбы?

Дата: 07 Сен 2021

Автор: Сергей Васильев

В апреле 2021 года Microsoft анонсировала новую версию своей IDE – Visual Studio 2022, попутно объявив, что она будет 64-битной. Сколько мы этого ждали — больше никаких ограничений по памяти в 4 Гб! …

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

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно. Хотите узнать подробнее?
Принять