Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Security
Code

Насколько безопасны ваши Open-Source JavaScript-зависимости?

by
Length:MediumLanguages:

Russian (Pусский) translation by Masha Kolesnikova (you can also view the original English article)

Современные разработчики JavaScript любят npm. GitHub и реестр npm являются лучшим выбором разработчика для поиска любого пакета. Модули с открытым исходным кодом повышают производительность и эффективность, предоставляя разработчикам множество функций, которые вы можете использовать в своем проекте. Справедливо сказать, что если бы не эти open-source пакеты, большинство фреймворков сегодня не существовало бы в их нынешнем виде.

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

Тем не менее, одним из факторов, который упускается из виду, является риск. Хотя эти сторонние модули особенно полезны в своей области, они также создают некоторые угрозы безопасности для вашего приложения.

Уязвимы ли библиотеки с открытым исходным кодом?

Зависимости OSS действительно уязвимы для эксплойтов и компрометации. Давайте посмотрим на несколько примеров:

Недавно была обнаружена уязвимость в пакете, с названием eslint-scope, который является зависимостью нескольких популярных пакетов JavaScript, таких как babel-eslint и webpack. Аккаунт сопровождающего пакета был взломан, и хакеры добавили в него вредоносный код. К счастью, кто-то узнал об этом достаточно скоро, и, как сообщается, ущерб был ограничен несколькими пользователями.

Недавно было обнаружено, что Moment.js, одна из наиболее часто используемых библиотек для анализа и отображения дат в JavaScript, имеет уязвимость с серьезностью 7,5. Эксплойт сделал его уязвимым для атак ReDoS. Патчи были быстро выпущены, и они помогли решить проблему довольно быстро.

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

Итак, как мы можем уменьшить эти риски? В этой статье я расскажу о некоторых лучших отраслевых стандартах, которые вы можете использовать для защиты ваших зависимостей.

1. Следите за зависимостями вашего приложения

Логически говоря, с ростом числа зависимостей риск попадания в уязвимый пакет также может возрасти. Это справедливо в равной степени для прямых и косвенных зависимостей. Хотя нет причин прекращать использование пакетов с открытым исходным кодом, всегда полезно отслеживать их.

Эти зависимости легко обнаруживаются и могут быть такими же простыми, как и запуск npm ls в корневом каталоге вашего приложения. Вы можете использовать аргумент –prod, который отображает все производственные зависимости, и аргумент –long для сводки описания каждого пакета.

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

2. Избавьтесь от пакетов, которые вам не нужны

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

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

Как вы проверяете наличие таких неиспользуемых зависимостей? Вы можете сделать это с помощью инструмента depcheck. Depcheck сканирует весь ваш код на предмет команд requires и import. Затем он сопоставляет эти команды с установленными пакетами или пакетами, упомянутыми в вашем package.json, и предоставляет вам отчет. Команду также можно изменить с использованием различных флагов, что упрощает автоматизацию проверки неиспользуемых зависимостей.

Установите depcheck с помощью:

3. Найдите и исправьте критические уязвимости безопасности

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

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

Самый удобный инструмент - это npm audit. Audit - это скрипт, выпущенный с версией npm 6. Платформа Node Security Platform изначально разработала аудит npm, а затем реестр npm приобрел его. Если вам интересно узнать, что такое аудит npm, вот цитата из официального блога:

Аудит безопасности - это оценка зависимостей пакетов для уязвимостей безопасности. Аудиты безопасности помогают защитить пользователей вашего пакета, позволяя находить и устранять известные уязвимости в зависимостях. Команда npm audit отправляет описание зависимостей, настроенных в вашем пакете, в реестр и запрашивает отчет об известных уязвимостях.

Сгенерированный отчет обычно содержит следующие данные: имя затронутого пакета, серьезность и описание уязвимости, путь и другую информацию, а также, если доступно, команды для применения исправлений для устранения уязвимостей. Вы даже можете получить аудиторский отчет в JSON, запустив npm audit --json.

Кроме того, npm также предлагает помощь в том, как действовать на основе отчета. Вы можете использовать команду npm audit fix, чтобы исправить проблемы, которые уже были найдены. Эти исправления обычно выполняются с помощью управляемых обновлений или патчей.

Не стесняйтесь обращаться к документации npm для получения дополнительной информации.

4. Замените устаревшие библиотеки внутренними альтернативами

Концепция open-source безопасности сильно зависит от количества глаз, которые следят за этой конкретной библиотекой. Пакеты, которые активно используются, более внимательно отслеживаются. Следовательно, существует большая вероятность того, что разработчик мог решить все известные проблемы безопасности в этом конкретном пакете.

Давайте возьмем пример. На GitHub есть много реализаций веб-токенов JSON, которые вы можете использовать с вашей библиотекой Node.js. Однако те, что не находятся в активной разработке, могут иметь критические уязвимости. Одна из таких уязвимостей, о которой сообщает Auth0, позволяет любому создавать свои собственные «подписанные» токены с любой полезной нагрузкой, которую они хотят.

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

5. Всегда выбирайте библиотеку, которая находится в активной разработке

Возможно, самый быстрый и эффективный способ определить активность определенного пакета - это проверить скорость его загрузки по npm. Вы можете найти это в разделе Stats на странице пакета npm. Также можно автоматически извлекать эти цифры, используя API статистики npm или просматривая статистику на npm-stat.com. Для пакетов с репозиториями GitHub вы должны проверить историю коммитов, систему отслеживания ошибок и все соответствующие запросы.

6. Часто обновляйте зависимости

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

Например, давайте возьмем уязвимость регулярного выражения отказа в обслуживании (ReDoS), о которой сообщалось в пакете HMAC «hawk» в начале 2016 года. Эта ошибка в npm audit fix была быстро устранена, но только в последней основной версии, 4.x. Более старые версии, такие как 3.x, были исправлены намного позже, хотя они были в равной степени подвержены риску.

Поэтому, как правило, ваши зависимости менее подвержены ошибкам безопасности, если они используют последнюю доступную версию.

Самый простой способ проверить, используете ли вы последнюю версию, - использовать команду npm outdated. Эта команда поддерживает флаг -prod для игнорирования любых зависимостей dev и --json для упрощения автоматизации.

Регулярно проверяйте пакеты, которые вы используете, чтобы проверить дату их изменения. Это можно сделать двумя способами: через пользовательский интерфейс npm или запустив npm view <package> time.modified.

Заключение

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

  1. Используйте зависимости с открытым исходным кодом, которые находятся в активной разработке.
  2. Обновите и контролируйте свои компоненты.
  3. Просмотрите свой код и напишите тесты.
  4. Удалите нежелательные зависимости или используйте альтернативы.
  5. Используйте инструменты безопасности, такие как npm audit, для анализа ваших зависимостей.

Если у вас есть какие-либо мысли о безопасности JavaScript, не стесняйтесь делиться ими в комментариях.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.