Комментарии 28
На фронте стоит использовать CSP и IFrame
На бэкэнде — изоляция контейнера от внешней среды и мониторинг странных запросов
Может и ещё что-то есть, знающие — подскажите.
Думайте перед тем как что-то ставитьnpm install:
Думаю, если бы JS наконец обзавёлся тем, что в других языках называется «стандартной библиотекой», проблем бы немного убавилось.
в ноде достаточно обширная стандартная библиотека, так что это не поможет.
Иногда вместе с минификацией из кода вырезаются неиспользуемые части, например информация для отладки. В этом случае минимизированный код будет быстрее его обычной версии. Так делает, например, lodash. Вот тут есть объяснение от автора библиотеки
Но конкретно в этом случае – это было сделано, чтобы получше замести следы. Никто же не всматривается в минифицированный код?
Непонятно другое, зачем вообще распространять минифицированные библиотеки через npm — все, кто заботится о минификации, в любом случае собирают проект инструментами, которые минифицируют код проекта — почему бы не использовать этот же процесс и для минификации зависимостей? Это бы немного усложнило сокрытие вредоносного кода, потому что любой не читаемый код автоматически бы вызывал подозрение.
Добросовестные разработчики и так добавляют необфусцированную версию своей библиотеки в отдельную папку в репозитории. Через npm подтягивается минифицированная версия, а если ты хочешь посмотреть, что там в библиотеке происходит — добро пожаловать на github, тут у тебя есть полная версия с человекопонятными названиями переменных, комментариями по jsdoc'у, в общем рай. Но это конечно идеальный случай
Добросовестные разработчики
Так новый разработчик таким и выглядел по началу )
А дальше положил в GitHub необфусцированную хорошую версию, а в минифицированную сборку — с закладкой. Ведь никто не делает контрольную минификацию и сверку для проверки закладок.
если мой npm run dev начнет обфусцировать также 100500 зависимостей из node_modules, то хот-релоад начнет работать один раз в день.
Мне кажется нет ничего плохого, если код зависимостей будет собран один раз и потом минифициован и закеширован с привязкой к конкретной версии. Тогда хот-релоад своего кода не будет каждый раз пересобтрать зависимости. А если их версия изменилась, то еще раз собрать не проблемы.
А зачем это делать при каждом запуске, зависимости-то изменяются редко, а минифицировать повторно нужно только изменившиеся файлы. Так что тормознёт только первый запуск, и большой беды в этом быть не должно.
Нет, к сожалению. Мне пока не попадались проекты, в которых хватало бы на это ресурсов. Но я крайне придирчиво отбираю используемые в проекте библиотеки, и нередко реализую нужный функционал самостоятельно вместо того, чтобы добавить ещё одну зависимость в проект.
Здесь требуется баланс, если вообще всё писать самостоятельно то получится стадо велосипедов, которые постоянно нужно допиливать, и на написание которых уйдёт безумное количество времени, которого у большинства проектов тупо нет… но если для любой мелкой проблемы искать готовые решения — результат будет ничуть не лучше, потому что каждая лишняя зависимость помимо быстрого решения текущей проблемы тащит с собой кучу новых проблем и рисков.
Мне тоже. Я бы даже так сказал — если у вас внезапно хватило времени проанализировать чужой код полноценно — вы могли бы за сравнимое время написать свой.
Более того, я подозреваю, что задача review кода зависимостей аналогична тому, что делают антивирусы — является ли поведение данного компонента легальным, или это вредонос? И она не решается полноценно ни одним инструментом. Если вообще решается, даже теоретически.
Ведь в данном конкретном примере были задействованы всего лишь два компонента, а представим себе, что их десяток, и вредоносный код размазан по всем. И работает, если они все установлены. Когда анализируем код компонента отдельно, находим там вполне безобидные функции.
Что это у нас тут? Ага, сера. Селитра. Уголь. Вроде все по отдельности безопасны. И только когда их смешали — получился порох.
Все что нужно — создать условия, чтобы все нужные компоненты оказались в одном месте. Реклама, социальная инженерия, еще что-то из той же оперы, на выходе получается бабах.
вы могли бы за сравнимое время написать свой
Возможно, но это не повод писать свой. Проблема велосипедов не в том, чтобы их написать достаточно хорошо, а в том, что после написания начинается процесс поддержки. Кроме того, автор чужого кода нередко обладает большей компетенцией в данной области, у его варианта уже сложилось коммьюнити, которое репортит ему и помогает заточить решение под реальные use cases — в общем, ввязываться в поддержку своего варианта по причине "я такое могу сам написать не хуже" — дурная идея. Исключение — ситуации, когда поддержки явно не потребуется.
В остальном Вы правы, но напрашивающееся решение не использовать вообще сторонних зависимостей — это не решение, потому что обойдётся намного дороже аудита сторонних зависимостей.
Нужно что-то вроде такого: https://habr.com/ru/post/336334/
Объясняем бэкдор в event-stream