Paraquire, или Перестаньте доверять библиотекам
Комментарии 18
-
24.08.17 в 23:23
+5
Почему такой флаг до сих пор не введён — неясно.
npm install --ignore-scriptsКак подобные проблемы решаются в других языках, в частности, в Ruby и Python?
Насколько я знаю — да никак. Мир не идеален, дерьмо случается, но в данном случае не так уж часто. Честно говоря и ни разу не столкнулся с вредоносным модулем на практике, хотя уже лет 5 как использую npm. Повышенное внимание к npm в этом контексте обусловленно в первую очередь, его популярностью. Тем не меннее, считаю что автор предложил неплохое решение.
-
25.08.17 в 02:14
0
Может быть вместо этого проксировать встроенные модули, в хэндлере try {throw} catch, по стэку смотреть, откуда была вызвана функция и либо разрешать и делать что попрошено, либо пробрасывать исключение наверх… Хотя не, производительность просядет, наверное…
-
25.08.17 в 08:56
0
Ошибку не обязательно кидать, чтобы получить из неё стек.
new Error('stack trace').stackНо взятие стека на каждый чих — весьма не быстро, да.
-
-
25.08.17 в 02:41–1
Размазывать права по всему коду приложения?
Более того если один внешний модуль подключается их двух точек вашего приложения? — Что произойдет если они укажут разные права?
Вариантом получше видится вызов библиотеки в одной точке приложения, и там же определить права для всех внешних модулей (ну или вообще в отдельном конфиг-файле)-
25.08.17 в 09:380
Модуль загрузится с разными правами. Компиляция — один раз, запуск в контекстах — в двух разных. Вот, в тестах есть: github.com/nickkolok/paraquire/blob/master/tests/manage-builtin-fs/main.js
-
-
25.08.17 в 05:27
+3
Ни в коем случае нельзя решать этот вопрос изменением исходных кодов, еще один уровень мета-программирования JS не выдержит.
Решение такое: подменяем require, это не проблема, в отдельном конфиг-файле указываем какие модули мокать, и какие у них права, тут можно создать группы прав.
В идеале, требуемые права должны быть в package.json самого пакета, как у приложений в мобильных сторах.Еще вариант, уровень доверия пакета определять на основе его использования в крупных репозиториях, а уж крупные компании могут и должны позволить себе аудит безопасности.
-
25.08.17 в 10:110
В идеале, требуемые права должны быть в package.json самого пакета
Разумеется. Потенциальный злоумышленник пусть сам указывает, какие права ему нужны.
-
-
25.08.17 в 09:22
+1
Да что же все так привязались к бедному npm. Можно подумать, с другими менеджерами пакетов что-то по другому. Вопрос безопасности решается легко — отсматривай, что ты включаешь, и фиксируй версию. Всё. Не надо делать вид, что у вас там чёрный ящик, который надо ограничивать.
Кстати, автоматические анализаторы пакетов на предмет вредоносного кода уже давно есть, и это тоже нормально, хотя ручной проверки кода ничто не заменит.
-
25.08.17 в 09:410
Лично я привязался к npm исключительно потому, что на NodeJS пишу, а на Python и на Ruby — только читаю.-
25.08.17 в 09:550
Nuget — всё то же самое
Composer — всё то же самое
Maven — то же самое
В последнее время всё больше компонентов используется напрямую с гитхаба — тем более всё то же самое. И это только примеры с тех языков, с которыми я непосредственно работал.Тут возникает очевидный компромис между богатством экосистемы и её безопасностью. Если каждый пакет будет отсматривать специальные люди, то рост их количества и скорости обновлений будет заметно ограничен производительностью этих людей.
Более того — даже наличие специальных людей не гарантирует, что в пакете случайно не будет функции, которая разнесёт всю систему (привет яндекс диску, один из релизов которого делал rm /rf).
И ещё одна бочка дёгтя в вашу каплю мёда — проверка разрешений никоим образом не гарантирует то, что нельзя некорректно воспользоваться выданными разрешениями. Например, пакету может требоваться доступ к файловой системе для записи логов\картинок\кеша\чего угодно. Естественно, этим можно злоупотребить как угодно. Или, к примеру, вы дали права на внешние коннекты. Получите сразу возможность использования зловреда, который отсылает на левый сервер ваши переменные окружения или что угодно ещё.
Так что такой подход очень вреден — это иллюзия безопасности вместо осознанного принятия рисков и принятия корректных мер по борьбе с ними.
-
25.08.17 в 10:310
Нужен CORS для NodeJS:-)
-
25.08.17 в 10:460
Например, пакету может требоваться доступ к файловой системе для записи логов\картинок\кеша\чего угодно.
Но ведь для этого он будет использовать другую библиотеку
-
-
-
25.08.17 в 10:17
0
Думаю, все потому что, что идея микромодулей в основном используется только в npm. В pypi, например, так не очень принято.
-
25.08.17 в 10:200
Таки большие модули отличаются только тем, что вы сразу отказываетесь от идеи проверять, что там внутри:)
Ну и нет — что джава, что PHP приложения сейчас обычно тоже тащат с собой кучу сторонних модулей. Но про это почему-то никто не пишет.
-
25.08.17 в 10:26
0
Таки большие модули отличаются только тем, что вы сразу отказываетесь от идеи проверять, что там внутри:)
А еще тем, что большой модуль так просто не напишешь. Поэтому почти за каждым из них стоит какая-то организация или конкретный человек, который поддерживает модуль продолжительное время, поэтому словить все описанные проблемы с такими пакетами довольно сложно. Остается разве что проблема неправильных имен, но тут уже ничего не поделать.
Ну и да, в силу того, что я не очень дружу с документацией, то часто приходится лезть в код и смотреть :)
-
-
-
-
25.08.17 в 09:38+1
Получится ли у вас в последствии переопределить поведение ES modules (import) как require?-
25.08.17 в 09:510
Это ключевое слово, так что вряд ли. Многое зависит от того, будет ли реализация import лежать на v8 (и тогда что-то сделать с ней будет очень проблематично) или же осуществляться силами NodeJS (и тогда есть шанс, что что-то получится). Впрочем, не думаю, что нодовцы отменят require, всё-таки нода не питон, тут так ломать обратную совместимость не принято.
-
-
25.08.17 в 10:180
Как подобные проблемы решаются в других языках, в частности, в Ruby и Python?
Как уже написали, никак. Там просто нет микромодулей, поэтому данная проблема менее актуальна, так как сложно какому-то ноу-нейм пакету выбраться в топы и быть использованым в куче других пакетов.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
