Вступление

Цель шпаргалки - предложить подход к работе с уязвимыми сторонними зависимостями при их обнаружении и в зависимости от различных ситуаций.

Шпаргалка не ориентирована на инструменты, но содержит раздел инструменты, информирующий читателя о бесплатных и коммерческих решениях, которые можно использовать для обнаружения уязвимых зависимостей, в зависимости от уровня поддержки используемых технологий.

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

Контекст

В большинстве проектов используются сторонние зависимости для делегирования обработки различных видов операций, например, генерации документа в определенном формате, связи HTTP, синтаксического анализа данных в определенном формате и т. Д.

Это хороший подход, поскольку он позволяет команде разработчиков сосредоточиться на реальном коде приложения, поддерживающем ожидаемую бизнес-функцию. Зависимость вызывает ожидаемый недостаток, на котором теперь зиждется безопасность реального приложения.

Этот аспект упоминается в следующих проектах:

Исходя из этого контекста, для проекта важно убедиться, что все реализованные сторонние зависимости не содержат каких-либо проблем безопасности, и если они содержат какие-либо проблемы безопасности, команда разработчиков должна знать об этом и применять необходимые меры по защите уязвимого приложения.

Настоятельно рекомендуется выполнять автоматический анализ зависимостей с самого начала проекта. В самом деле, если эта задача добавляется в середине или конце проекта, это может означать огромный объем работы для решения всех выявленных проблем, что, в свою очередь, возложит огромную нагрузку на команду разработчиков и может заблокировать продвижение проекта под рукой.

Примечание. В остальной части шпаргалки, когда мы говорим о команде разработчиков, мы предполагаем, что в команде есть участник с необходимыми навыками безопасности приложений или может ссылаться на кто-то в компании, обладающий такими навыками, чтобы проанализировать уязвимость, влияющую на зависимость.

Замечания об обнаружении

Важно помнить о различных способах решения проблемы безопасности после ее обнаружения.

1. Ответственное раскрытие информации

Смотрите описание здесь.

Исследователь обнаруживает уязвимость в компоненте, и после сотрудничества с поставщиком компонента он выдает CVE (иногда создается конкретный идентификатор уязвимости для поставщика, но обычно идентификатор CVE предпочтительнее), связанный с проблемой, позволяющей публично ссылаться. проблемы, а также доступные способы устранения / устранения.

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

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

2. Полное раскрытие информации

См. Описание здесь в разделе Компьютеры о Компьютерной безопасности.

Исследователь решает опубликовать всю информацию, включая код / ​​метод эксплуатации, на таких сервисах, как Список рассылки Full Disclosure, Exploit-DB.

Здесь CVE не всегда создается, тогда уязвимость не всегда находится в глобальной базе данных CVE, из-за чего инструменты обнаружения потенциально не видят, если инструменты не используют другие источники ввода.

Замечание о решении проблемы безопасности

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

Случаи

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

Если уязвимость воздействует на транзитивную зависимость, то действие будет предпринято для прямой зависимости проекта, потому что действие на транзитивную зависимость часто влияет на стабильность приложения.

Чтобы действовать в соответствии с транзитивной зависимостью, команда разработчиков должна полностью понимать все отношения / взаимодействие / использование от зависимости первого уровня проекта до тех пор, пока на зависимость не повлияет уязвимость системы безопасности. Эта задача занимает очень много времени.

Дело 1

Контекст

Поставщиком выпущена исправленная версия компонента.

Идеальные условия применения подхода

Для функций приложения существует набор автоматизированных модульных или интеграционных или функциональных тестов или тестов безопасности, использующих затронутую зависимость, позволяющую подтвердить, что функция работает.

Подход

Шаг 1:

Обновите версию зависимости в проекте в тестовой среде.

Шаг 2:

Перед запуском тестов возможны 2 пути вывода:

  • Все тесты проходят успешно, поэтому обновление можно отправить в производство.
  • Один или несколько тестов не прошли, возможны несколько путей вывода:
  • Сбой вызван изменением некоторых вызовов функций (например, подпись, аргумент, пакет и т. Д.). Команда разработчиков должна обновить свой код, чтобы он соответствовал новой библиотеке. Как только это будет сделано, повторно запустите тесты.
  • Техническая несовместимость выпущенной зависимости (например, требуется более поздняя версия среды выполнения), которая приводит к следующим действиям:
  • Сообщите об этом провайдеру.
  • Примените Случай 2, ожидая ответа от провайдера.

Случай 2

Контекст

Провайдер сообщает команде, что для устранения проблемы потребуется время, и поэтому исправленная версия не будет доступна через несколько месяцев.

Идеальные условия применения подхода

Провайдер может поделиться с командой разработчиков любым из перечисленных ниже:

  • Код эксплуатации.
  • Список функций, затронутых уязвимостью.
  • Обходной путь, чтобы предотвратить использование проблемы.

Подход

Шаг 1:

Если предусмотрен обходной путь, его следует применить и проверить в тестовой среде, а затем развернуть в производственной среде.

Если провайдер предоставил команде список затронутых функций, защитный код должен обернуть вызовы этих функций, чтобы гарантировать безопасность входных и выходных данных.

Более того, устройства безопасности, такие как брандмауэр веб-приложений (WAF), могут справляться с такими проблемами, защищая внутренние приложения с помощью проверки параметров и создания правил обнаружения для этих конкретных библиотек. Тем не менее, в этой шпаргалке основное внимание уделяется уровню приложения, чтобы исправить уязвимость как можно ближе к источнику.

Пример использования кода Java, в котором затронутая функция страдает от проблемы Удаленное выполнение кода:

code" style="box-sizing: inherit; background: transparent; border: 0px; color: var(--darkreader-text--md-default-fg-color--lightest); -webkit-tap-highlight-color: transparent; font-family: inherit; font-size: inherit; margin: 0px; padding: 0px; border-radius: 0.1rem; cursor: pointer; height: 1.5em; outline: none; outline-offset: 0.1rem; position: absolute; right: 0.5em; top: 0.5em; transition: color 0.25s ease 0s; width: 1.5em; z-index: 1;">public void callFunctionWithRCEIssue(String externalInput){
    //Apply input validation on the external input using regex
    if(Pattern.matches("[a-zA-Z0-9]{1,50}", externalInput)){
        //Call the flawed function using safe input
        functionWithRCEIssue(externalInput);
    }else{
        //Log the detection of exploitation
        SecurityLogger.warn("Exploitation of the RCE issue XXXXX detected !");
        //Raise an exception leading to a generic error send to the client...
    }
}

Если поставщик ничего не сообщил об уязвимости, можно применить Случай 3, пропустив шаг 2 этого случая. Мы предполагаем, что, по крайней мере, CVE была предоставлена.

Шаг 2:

Если провайдер предоставил команде код эксплуатации, а группа создала оболочку безопасности для уязвимой библиотеки / кода, выполните код эксплуатации, чтобы гарантировать, что библиотека теперь безопасна и не влияет на приложение.

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

Добавьте комментарий в проект README, объясняющий, что проблема (укажите соответствующий CVE) обрабатывается во время ожидания исправленной версии, потому что средство обнаружения будет продолжать выдавать предупреждение об этой зависимости.

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

Случай 3

Контекст

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

В этом случае единственной информацией, предоставляемой команде разработчиков, является CVE.

Примечания:

  • Этот случай действительно сложный, требует много времени и обычно используется в крайнем случае.
  • Если затронутая зависимость является библиотекой с открытым исходным кодом, тогда мы, команда разработчиков, можем создать патч и создать запрос на вытягивание - таким образом мы сможем защитить нашу компанию / приложение от источника, а также помочь другим защитить свои приложения.

Идеальные условия применения подхода

Ничего особенного, потому что здесь мы находимся в состоянии заплатить сами.

Подход

Шаг 1:

Если мы попали в этот случай из-за одного из следующих условий, рекомендуется начать параллельное исследование, чтобы найти другой компонент, который лучше обслуживается, или, если это коммерческий компонент с поддержкой, тогда оказать давление на поставщика с помощью вашего Директора по рискам (возможен откат Директор по информационной безопасности):

  • Провайдер не хочет исправлять проблему.
  • Провайдер вообще не отвечает.

Во всех случаях здесь нам нужно справиться с уязвимостью прямо сейчас.

Шаг 2:

Поскольку мы знаем уязвимую зависимость, мы знаем, где она используется в приложении (если это транзитивная зависимость, то мы можем определить зависимость первого уровня, используя ее, используя встроенную функцию IDE или используемую систему управления зависимостями (Maven, Gradle, Nuget, npm и т. Д.). Обратите внимание, что IDE также используется для идентификации вызовов зависимости.

Идентифицировать вызовы этой зависимости можно, но это первый шаг. Команде по-прежнему не хватает информации о том, какие исправления необходимо выполнить.

Чтобы получить эту информацию, команда использует содержимое CVE, чтобы узнать, какая уязвимость влияет на зависимость. Свойство description предоставляет ответ: внедрение SQL, удаленное выполнение кода, межсайтовый скриптинг, подделка межсайтовых запросов и т. Д.

После определения двух вышеуказанных пунктов команда знает, какой тип исправления необходимо применить (Случай 2 с защитным кодом) и куда его добавить.

Пример:

У команды есть приложение, использующее API Джексона в версии, представленной CVE-2016–3720.

Описание CVE выглядит следующим образом:

code" style="box-sizing: inherit; background: transparent; border: 0px; color: var(--darkreader-text--md-default-fg-color--lightest); -webkit-tap-highlight-color: transparent; font-family: inherit; font-size: inherit; margin: 0px; padding: 0px; border-radius: 0.1rem; cursor: pointer; height: 1.5em; outline: none; outline-offset: 0.1rem; position: absolute; right: 0.5em; top: 0.5em; transition: color 0.25s ease 0s; width: 1.5em; z-index: 1;">XML external entity (XXE) vulnerability in XmlMapper in the Data format extension for Jackson
(aka jackson-dataformat-xml) allows attackers to have unspecified impact via unknown vectors.

Основываясь на этой информации, команда определяет, что необходимое исправление будет заключаться в добавлении предварительной проверки любых данных XML, передаваемых в Jakson API, для предотвращения уязвимости внешний объект XML (XXE).

Шаг 3:

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

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

Случай 4

Контекст

Уязвимая зависимость обнаруживается в одной из следующих ситуаций, когда поставщик не знает об уязвимости:

  • Через открытие поста с полным раскрытием информации в Интернете.
  • Во время теста на проникновение.

Идеальные условия применения подхода

Провайдер сотрудничает с вами после уведомления об уязвимости.

Подход

Шаг 1:

Сообщите провайдеру об уязвимости, поделившись с ним публикацией.

Шаг 2:

Используя информацию из сообщения о полном раскрытии информации или отзывов об эксплуатации пентестера, если провайдер сотрудничает, тогда примените Случай 2, в противном случае примените Случай 3, и вместо анализа информации CVE команде необходимо проанализировать информацию из полной сообщение о раскрытии информации / отзыв об эксплуатации пентестера.

Инструменты

В этом разделе перечислены несколько инструментов, которые можно использовать для анализа зависимостей, используемых проектом, с целью обнаружения уязвимостей.

В процессе выбора инструмента обнаружения уязвимых зависимостей важно убедиться, что он:

  • Использует несколько надежных источников входных данных для обработки обоих способов раскрытия уязвимостей.
  • Поддержка отметки проблемы, возникшей в компоненте, как ложноположительной.
  • Бесплатно
  • Проверка зависимости OWASP:
  • Полная поддержка: Java, .Net.
  • Экспериментальная поддержка: Python, Ruby, PHP (композитор), NodeJS, C, C ++.
  • НПМ Аудит
  • Полная поддержка: Node.js, JavaScript.
  • Отчет в формате HTML доступен через этот модуль.
  • OWASP Dependency Track можно использовать для управления уязвимыми зависимостями в организации.
  • Коммерческий
  • Snyk (доступен бесплатный и открытый исходный код):
  • Полная поддержка многих языков и пакетного менеджера.
  • JFrog XRay:
  • Полная поддержка многих языков и пакетного менеджера.
  • Renovate (позволяет обнаружить старые зависимости):
  • Полная поддержка многих языков и пакетного менеджера.
  • Requires.io (позволяет обнаруживать старые зависимости - доступен открытый исходный код и бесплатный вариант):
  • Полная поддержка: только Python.

"Источник"



Флориан GOTO - Medium
Прочтите письмо Флориана GOTO на Medium. Все еще учусь. Каждый день Флориан GOTO и тысячи других людей читают… gotoflorian-pro.medium.com





Шпаргалка по безопасности Node.js от OWASP
Список передовых методов, которым следует следовать при разработке приложений Node.js. javascript.plainenglish.io





Памятка по политике безопасности контента для разработчиков JavaScript
Введение itnext.io





Памятка по ведению журнала из OWASP
Введение gotoflorian-pro.medium.com



Больше контента на plainenglish.io