[в закладки] 23 рекомендации по защите Node.js-приложений

[Senyaak]

Так есть ведь github.com/eslint/typescript-eslint-parser — или я чтото не допонял?

[Zibx]

Пункты 15, 16 и 17 входят в первый.
Eval — не зло само по себе, а компиляция во время выполнения. Такая компиляция позволяет сильно ускорить код один раз сгенерировав точные методы под конкретную задачу из диапазона возможных решений. Уменьшить нагрузку на канал в случае очень похожего набора методов. Увеличить переиспользование кода (снизить вероятность возникновения ошибок получающихся при копи-пасте и особенно при последующих изменениях таких частей). Естественно, нельзя исполнять код полученный от клиента и этот инструмент следует очень осторожно использовать, но он ничем не отличается от подгрузки js файла сгенерированного сервером (в него тоже можно включить XSS если есть такое желание или в силу криворукости).

[Free_ze]

Eval — не зло само по себе… позволяет… снизить вероятность возникновения ошибок получающихся при копи-пасте

Очень сомнительный аргумент. Метапрограммирование обычно лишь повышает сложность как разработки, так и тестирования.

[Taraflex]

Дополню. С приходом webpack такие операции можно удобно проделывать на этапе сборки, используя в проекте небольшие самописные лоадеры, определив в конфигурации кастомную директорию для поиска лоадеров.

[mwizard]

По поводу "13. Запускайте Node.js от имени пользователя, не обладающего root-привилегиями" — несмотря на то, что в контейнере пользователь имеет uid 0 и называется root, реальных рутовых привилегий у него нет, если только контейнер не был запущен с флагом --privileged, либо нужные привилегии не были добавлены через --cap-add. Поэтому в чистом контейнере перенаправить iptables невозможно, а привилегии эффективного пользователя не отличаются от таковых у nobody.

[taliban]

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

[mwizard]

Тем не менее, в статье говорится именно про докер — «Например, именно так всё по умолчанию настроено в контейнерах Docker. Рекомендуется создавать пользователя, не обладающего root-правами, и либо встраивать его в образ Docker, либо запускать процесс от имени этого пользователя, вызывая контейнер с флагом -u username.» Вышеуказанные рекомендации бесполезны. Не навредят, но и пользы никакой.

[taliban]

Да, вы правы, этот момент я упустил, некоторые очевидные вещи я пропускал :)

[Hilbert]

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

Вы ошибаетесь — не использовать root в контейнере это очень распространенная best practice:
blog.dscpl.com.au/2015/12/don-run-as-root-inside-of-docker.html
opensource.com/business/14/7/docker-security-selinux
medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b
Так что контейнер не является 100% защитой в этом плане, по крайней мере без использования User Namespaces. Неспроста же облачные сервисы вроде Google Cloud запускают пользовательские контейнеры на отдельных виртуальных машинах — контейнеры не являются надежным методом изоляции.

[mwizard]

Может проблема не в руте, а в mount-ах вида docker run --rm -it -v /:/rootfs busybox sh и полнейшем игнорировании авторами этих "разоблачающих" статей основных принципов работы неймспейсов? Докер запускается с правами рута. При установке докер говорит прямым текстом, что он увеличивает attack surface, поэтому к демону докера должен иметь доступ только рут и судоэры, и добавлять пользователя в группу докера — это риск для безопасности, т.к. фактически выдаются рутовые привилегии. Если кто-то невнимательно читает сообщения при установке, а потом делает из этого сенсацию...

tl;dr — не надо монтировать корневую фс хоста внутрь контейнера, а потом удивляться. Попробуйте лучше вырваться из обычного docker run --rm -it ubuntu и сделать с хостом хоть что-нибудь.

UPD: увидел в одной из ваших статей, что у контейнера якобы есть доступ к /dev/mem и /dev/sd*. Наверное, у меня неправильный контейнер, потому что вот, что лежит в моем /dev:

root@a78864fc7413:/# find /dev 
/dev
/dev/console
/dev/core
/dev/stderr
/dev/stdout
/dev/stdin
/dev/fd
/dev/ptmx
/dev/urandom
/dev/zero
/dev/tty
/dev/full
/dev/random
/dev/null
/dev/shm
/dev/mqueue
/dev/pts
/dev/pts/0
/dev/pts/ptmx

[Hilbert]

Не монтируя /, вы отнюдь не защищаете себя от всех возможных атак. Вы понимаете, насколько огромна attack surface, учитывая, что хост и контейнеры используют одно ядро? Вы понимаете, что стоит найти какую-то уязвимость, которые наверняка есть, и с UID 0 атакующий нанесет куда больше вреда, чем с UID обычного пользователя после неймспейсинга или просто запуская процесс в контейнере не от root?

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

Не говоря уж о том, что прямо в документации Docker написано:

Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container.

docs.docker.com/engine/security/security/#conclusions

[MikailBag]

С каких это пор cluster.fork() стал безопасной песочницей?

[SemaIVVV]

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

А если ограничивает, то атакующий сможет навсегда запретить вход самому админу в админку :)
Не у всех админов есть выделенный IP, к которому можно привязать вход, а не привязанный IP — и вы больше сами никогда не сможете войти в панель, атакующий будет на автомате каждые 5-15 минут пытаться войти, и вы ничего не сможете сделать со своей панелью.

[VolCh]

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