Comments 27
Иногда кажется, что одно из предназначений экосистемы NodeJS/NPM — это пособие для изучения ИБ))
pypi.org/project/russian_roulette
(Не устанавливать. Вот почему: github.com/charlesreid1/dont-sudo-pip/blob/source/setup.py )
в идеале, это могли бы реализовать на уровне npm — автоматически запускается виртуальная машина с минимальным линухом на борту, к ней подключается папка проекта как жесткий диск — и после install все отключается, ты работаешь в обычной среде
Не взлетело.
Тут вариантов не так много, т.к. тот же пакет будет крутиться у вас на проде
Один из вариантов — не использовать сторонние пакеты в рантайме без крайней необходимости.
но так вы правы, в большинстве случаев этого недостаточно для полной защиты
Приложения не используют, а входящие в них пакеты?
С другой стороны всё распространяется исходниками и в теории можно накручивать автоматику с проверками. А в nuget распространяют бинари, которым надо доверять. Хорошо хоть отказались от скриптов в новых версиях
У автора fake-template нет времени, чтобы отделять тесты от непосредственного кода
Видимо, автор любит Rust, в котором это распространенная практика.
Несмотря на всё это npm отлично справляется. Есть система безопасности, пакеты мониторятся.
Все пакеты найденные в статье имеют 0 а то и меньше установок. Учитывая популярность npm не стоит этому удивляться. Конечно бывают и большие хаки (как с eslint) и они являются желаймой целью хакеров.
Думаю централизованность npm тут выигрывает у например децентрализованого go. Кто будет проверять все сущ репы? А если популярная репа окажется хакнута?
Думаю централизованность npm тут выигрывает у например децентрализованого go. Кто будет проверять все сущ репы? А если популярная репа окажется хакнута?
В чем же выигрывает?
- В том, что есть какие-то парни в npm, на которых в случае взлома можно спихнуть вину?
- В том, что твоим пакетом управляет какая-то левая компания? Вспомните историю с leftpad.
- В том, что пакет != код из репозитория, и уязвимости как с тем же eslint в принципе возможны?
Кто будет проверять все сущ репы?
Это задача инженера, который подключает пакет.
А если популярная репа окажется хакнута?
В полной мере от этого никто не застрахован. У того же Go и в случае mod и в случае dep отсутствуют preisntall, postinstall и вот это вот все, что закрывает довольно большой источник уязвимостей.
В том, что есть какие-то парни в npm, на которых в случае взлома можно спихнуть вину?
Это плюс npm что есть хотя бы кто-то кто проверяет и дорожит своей репутацией.
В том, что твоим пакетом управляет какая-то левая компания? Вспомните историю с leftpad.
Вспомнил. Что дальше? Из-за того что есть npm пакет бытро вернули, убрали возможность удалять пакеты.
А что было бы если кто-то удалить свою Go репу? А если она была бы такая же популярная как left-pad? Думаю прошло бы приличное количество времени прежде чем все зависимые репы обновились бы и сколько всё было бы сломано никто не знает.
История с left-pad стала такой знаменитой благодоря размером npm.
Это задача инженера, который подключает пакет.
Это справедливо как для npm, так и для go.
В полной мере от этого никто не застрахован. У того же Go и в случае mod и в случае dep отсутствуют preisntall, postinstall и вот это вот все, что закрывает довольно большой источник уязвимостей.
Тут согласен, это минус npm.
Это плюс npm что есть хотя бы кто-то кто проверяет и дорожит своей репутацией.
Ок, вот смотрите: есть github на нем есть проект MyVendor\MyProject. Проект дико популярен, все здорово, его аудитом, пусть и косвенно занимаются люди, которые его используют. То, что я вижу в репозитории и то, что загрузится в зависимости — одно и то же.
Теперь берем npm. Так же с пакетом MyProject. Как я могу посмотреть код пакета? Только установив его через npm. Потому, что содержимое пакета и содержимое репозитория — это разные вещи.
Теперь вернемся к аудиту, который администрация npm вынуждена делать, что бы оставаться востребованной. Этот самый аудит когда происходит? Постфактум, в зависимости от популярности пакета. Это значит, что от момента публикации до нахождения проблем может пройти довольно много времени. Если проект не популярен — до него могут руки и не дойти.
Теперь вопрос, а за что они (npm) отвечают, особенно с учетом того, что большинство пакетов под MIT/BSD/WTFPL?
Вспомнил. Что дальше? Из-за того что есть npm пакет бытро вернули, убрали возможность удалять пакеты.
Не вспомнили. Причина удаления leftpad автором заключается в том, что другой пакет (kik) этого же автора администрация npm отозвала, поставив перед фактом, нарушая собственные правила.
12 странных вещей, которые могут произойти после установки npm пакета