Хотя программное обеспечение с открытым исходным кодом может быть чрезвычайно полезным, его использование сопряжено с некоторыми серьезными рисками. Многие разработчики не знают о степени этих рисков или даже о том, что они вообще используют программное обеспечение с открытым исходным кодом! Согласно отчету, в среднем веб-приложение или API имеют 26,7 серьезных уязвимостей. Большинство организаций часто имеют десятки тысяч приложений, которые потенциально могут быть фатальными!

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

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

Нарушение Эквифакса

Если вы не знаете, что такое Equifax, это одно из агентств кредитной информации, которое оценивает финансовое состояние почти всех жителей Соединенных Штатов. Это автоматически означает, что у него есть личная информация более 95% граждан США, включая номера социального страхования, адреса, номера кредитных карт, даты рождения и т. д. В сентябре 2017 года Equifax опубликовала заявление, в котором говорится, что хакеры украли конфиденциальную информацию 147 миллионов люди.

Главный вопрос: как хакеры это сделали? Как хакеры получили доступ к серверам самых важных компаний в Соединенных Штатах?

Ответ; случайно. Хакеры сканировали Интернет в поисках уязвимых серверов и наткнулись на спорный сервер Equifax. Затем они использовали известную уязвимость Apache Struts для взлома трех серверов Equifax.

Вот как работала уязвимость Struts: если злоумышленники отправляли HTTP-запросы с вредоносным кодом, спрятанным в заголовке типа контента, Struts можно было обманом заставить выполнить этот код, потенциально открывая систему, на которой работал Struts, для дальнейшего вторжения.

Хакеры смогли провести до 6 месяцев на серверах Equifax, прежде чем они были обнаружены и в конечном итоге удалены. К тому времени вред уже был нанесен. Equifax критиковали за все, от недостаточной безопасности до неуклюжей реакции на инцидент, а впоследствии высокопоставленных чиновников обвинили в правонарушениях.

Ограбление ESlint

В 2018 году была обнаружена уязвимость в модуле под названием eslint-scope, который является зависимостью от нескольких популярных пакетов JavaScript, таких как babel-eslint и webpack. Модуль был взломан хакером при попытке украсть токены из .npmrc. Хакер выпустил новый патч модуля с трояном в нем, и многие разработчики, которые использовали библиотеку, начали использовать новый патч.

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

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

Какие пакеты я использую?

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

Найти зависимости, которые вы используете, так же просто, как запустить npm 1s в родительской папке вашего приложения, чтобы увидеть, какие пакеты вы используете. Вы можете использовать параметр —prod, чтобы видеть только рабочие зависимости (которые больше всего влияют на вашу безопасность), и —long, чтобы получить краткий обзор каждого пакета.

Вы также можете использовать службы управления зависимостями, такие как bitHound и VersionEye, для составления списка и отслеживания используемых вами зависимостей. Как только вы узнаете все свои пакеты, следующий вопрос, который нужно задать:

Я все еще использую этот пакет?

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

Инструмент depcheck — лучший способ проверить наличие ненужных зависимостей. Depcheck ищет в вашем коде требования и команды импорта и сопоставляет их с пакетами, установленными или упомянутыми в вашем пакете .json, и создает отчет. Команду можно настроить различными способами с помощью командных флагов, что упрощает автоматическую проверку ненужных зависимостей. Следующий и, пожалуй, самый важный вопрос

Используют ли другие разработчики этот пакет?

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

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

Наконец, последний вопрос, который вы должны себе задать:

Есть ли в этом пакете известные уязвимости?

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

Сник упрощает выявление таких небезопасных пакетов. Вы можете запустить snyk тест в своем терминале или использовать веб-интерфейс, чтобы быстро проверить свои репозитории GitHub на наличие небезопасных зависимостей. Другие альтернативы тестирования можно найти на тестовой странице Snyk.

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

Выберите хороший хостинг репозитория

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

Если по какой-то причине вы не хотите использовать GitHub, вы можете использовать BitBucket, GitLab и Launchpad. Обратите внимание, что, хотя они также бесплатны, они гораздо менее популярны, а это означает, что на ваш код будет меньше внимания. Они также предлагают меньшую вовлеченность и предлагают менее полезные инструменты, чем GitHub. Просто выложи это там.

Обновляйте свои зависимости

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

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

Команда npm outdated — это самый быстрый способ узнать, используете ли вы самую последнюю версию. Эта команда поддерживает флаг -prod, чтобы игнорировать любые зависимости разработчиков, и флаг —json, чтобы упростить автоматизацию.

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

Используйте инструменты безопасности

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

  • RetireJs: RetireJS — это средство проверки зависимостей для JavaScript с открытым исходным кодом. Проект во многом связан с юзабилити. В результате он включает в себя сканер командной строки, а также плагины для Grunt, Gulp, Chrome, Firefox, ZAP и Burp. RetireJS также предоставляет инструмент проверки сайта для разработчиков JS, которые хотят узнать, используют ли они библиотеку JavaScript с известными уязвимостями.
  • Hakiri: Hakiri — это коммерческое приложение, которое использует статический анализ кода для обеспечения тестирования зависимостей для проектов GitHub на основе Ruby и Rails. Он предоставляет бесплатные чертежи для общедоступных проектов с открытым исходным кодом и премиум-планы для частных компаний. Он использует NVD и базу данных Ruby Advisory. Но они также хотят включить соединения со Slack, JIRA и Pivotal Tracker, а также поддержку других платформ, таких как Node.js и PHP.
  • Проверка зависимостей: проверка зависимостей — это хорошо поддерживаемая утилита командной строки с открытым исходным кодом от OWASP. Его можно использовать как самостоятельно, так и в составе инструментов для сборки. Проверка зависимостей совместима с Java, .NET, JavaScript и Ruby. Инструмент получает данные об уязвимостях исключительно из NIST NVD.

Заключение

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