Аутентификация (паспорт) достаточна для обеспечения безопасности с узлом JS backend server?

Достаточно ли PassportJS, использующих аутентификацию Facebook, для бэкенда iOS с узлом JS?

У меня есть пакет toobusy, который также отклоняет запросы, когда все становится занято (я предполагаю, что это было бы хорошо для DDoS-атак).

Я думаю использовать nginx в качестве обратного прокси-сервера для моего узла.Сервер JS также.

Какие еще меры безопасности можно масштабировать? Какие-то советы и рекомендации? Все, что связано с безопасностью, что я должен быть обеспокоен тем, что PassportJS аутентифицирован сессия не может справиться?

2 9
node.js ios security facebook backend

2 ответа:

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

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

Одна (большая) причина для размещения PasswordJS за обратным прокси (RP) заключается в том, что вы сможете чтобы обеспечить первую линию защиты для всего, что связано с HTTP: header / body lengths / data, разрешенными методами, повторяющимися / нежелательными заголовками и т. д.

Nginx / Apache/HAProxy предоставляют отличные возможности для обработки этих случаев, и с другой стороны, вы получаете хорошее разделение проблем: пусть обратный прокси-сервер обрабатывает безопасность, а PassportJS-аутентификацию. С точки зрения архитектуры, это также будет иметь больше смысла, потому что вы сможете скрыть номер и инфраструктуру PassportJS узлы. В принципе, вы хотите, чтобы это выглядело так, как есть только одна точка входа для ваших клиентов. Масштабирование также будет проще с этой архитектурой. Как всегда, убедитесь, что ваш RP(ы) сохраняет как можно меньше состояний, предпочтительно ни одного, чтобы масштабировать линейно.

Чтобы правильно настроить свой RP, вам нужно действительно понять, как работают протоколы PassportJS (в случае, если вы хотите предоставить больше методов аутентификации, чем просто Facebook). Зная это, вы можете настроить ваш RP (ы) к:

  • отклонить любой запрещенный метод HTTP запроса (TRACE, OPTION, PUT, DELETE и т. д.).
  • отклонять запросы / заголовки / полезные данные, превышающие известный размер.
  • балансировка нагрузки на узлы PassportJS.

Одна вещь, которую нужно искать с точки зрения балансировки нагрузки,-этолипкие сессии . Некоторые аутентификаторы хранят все свое состояние в зашифрованном файле cookie, другие представляют собой простой дескриптор сеанса, который может быть понят только узлом, который создал сеанс. Поэтому, если у вас нет общего доступа к сеансам для последнего типа (Если вам нужна устойчивость PassportJS), вам нужно настроить RP для обработки липких сеансов. Это должно быть максимальное количество состояния, которое они должны обрабатывать. Настроенный правильно, это может даже работать, если вам нужно перезапустить RP.

Как вы старательно указали, toobusy (или эквивалент) должен быть на месте, чтобы справиться с дросселированием. По моему опыту, с HAProxy немного проще работать, чем с другими RPs что касается дросселирования, но toobusy тоже должно работать нормально, особенно если вы уже знакомы с ним.

Еще одна вещь, которая может быть или не быть под вашим контролем, - это разделение сети. Очевидно, что RPs должны быть доступны, но они должны действовать как ретрансляторы для ваших узлов PassportJS. Лучше всего, если это возможно, поместить узлы аутентификации в отдельную сеть / DMZ от ваших внутренних серверов, так что они не могут быть напрямую доступны, кроме как через RP. Если их скомпрометировать, они не следует использовать в качестве ступеньки к бэкенду/внутренней сети.
7

Согласно паспортной документации: "поддержка аутентификации с использованием имени пользователя и пароля, Facebook, Twitter и многое другое."

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

Вы должны рассмотреть назначение приложения, оно поддерживает только аутентификацию Facebook или пользовательский процесс регистрации / входа. Если это второй вариант, то в таком случае, лучше не полагаться на authtoken любого социальные сети, такие как Facebook / Twitter или любые другие.

Лучший вариант-создать свой собственный токен, например токен JWT, и связать его с пользователем с нескольких платформ. Это поможет вам расширить рамки вашего проекта, чтобы интегрировать другие сайты социальных сетей.

Вот ссылка для интеграции JWT в NodeJS.

Https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens

Точно так же есть много других блогов и учебные пособия, доступные на рынке для интеграции JWT с NodeJS

2