From c1189d23ce71ca3cc08884306828f33fa615eaff Mon Sep 17 00:00:00 2001 From: Alexander Ivanov Date: Tue, 23 Jul 2019 08:18:35 +0300 Subject: [PATCH] commonsecuritybestpractices Signed-off-by: Alexander Ivanov --- README.russian.md | 2 +- .../commonsecuritybestpractices.russian.md | 99 +++++++++++++++++++ 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644 sections/security/commonsecuritybestpractices.russian.md diff --git a/README.russian.md b/README.russian.md index 89655190..5bfd3d80 100644 --- a/README.russian.md +++ b/README.russian.md @@ -785,7 +785,7 @@ null == undefined // true **TL;DR:** Это набор рекомендаций по безопасности, которые не связаны напрямую с Node.js -- реализация Node мало чем отличается от любого другого языка. Нажмите "Подробнее", чтобы просмотреть. -🔗 [**Подробнее: Common security best practices**](/sections/security/commonsecuritybestpractices.md) +🔗 [**Подробнее: Общие рекомендации по безопасности Node.js**](/sections/security/commonsecuritybestpractices.russian.md)

diff --git a/sections/security/commonsecuritybestpractices.russian.md b/sections/security/commonsecuritybestpractices.russian.md new file mode 100644 index 00000000..f62035c5 --- /dev/null +++ b/sections/security/commonsecuritybestpractices.russian.md @@ -0,0 +1,99 @@ +[✔]: ../../assets/images/checkbox-small-blue.png + +# Общие рекомендации по безопасности Node.js + +Раздел общих рекомендаций по безопасности содержит рекомендации, которые стандартизированы во многих платформах и соглашениях, например, запуск приложения с SSL/TLS должен быть общим руководством и соглашением, которое следует соблюдать при каждой настройке для достижения значительных преимуществ безопасности. + +## ![✔] Используйте SSL/TLS для шифрования соединения клиент-сервер + +**TL;DR:** Во времена [бесплатных SSL/TLS-сертификатов](https://letsencrypt.org/) и их простой настройки вам больше не нужно взвешивать преимущества и недостатки использования безопасного сервера, потому что такие преимущества, как безопасность, поддержка современных технологий и доверие, явно перевешивают такие недостатки, как минимальные издержки по сравнению с чистым HTTP. + +**Иначе:** Злоумышленники могут выполнять атаки "человек посередине", следить за поведением ваших пользователей и совершать еще более злонамеренные действия, когда соединение не зашифровано. + +🔗 [**Read More: Запуск безопасного Node.js сервера**](/sections/security/secureserver.russian.md) + +

+ +## ![✔] Безопасное сравнение секретных значений и хэшей + +**TL;DR:** При сравнении секретных значений или хэшей, таких как код HMAC, вы должны использовать [`crypto.timingSafeEqual(a, b)`](https://nodejs.org/dist/latest-v9.x/docs/api/crypto.html#crypto_crypto_timingsafeequal_a_b) функция Node обеспечивает готовую работу, начиная с Node.js v6.6.0. Этот метод сравнивает два заданных объекта и продолжает сравнивать, даже если данные не совпадают. Методы сравнения равенства по умолчанию просто возвращались бы после несоответствия символов, позволяя рассчитывать время атаки на основе длины операции. + +**Иначе:** Используя операторы сравнения равенства по умолчанию, вы можете предоставить критическую информацию, основываясь на времени, затраченном на сравнение двух объектов. + +

+ +## ![✔] Генерация случайных строк с использованием Node.js + +**TL;DR:** Использование специально созданной функции, генерирующей псевдослучайные строки для токенов и других чувствительных к безопасности случаев использования, на самом деле может быть не таким случайным, как вы думаете, что делает ваше приложение уязвимым для криптографических атак. Когда вам нужно создать безопасные случайные строки, используйте [`crypto.RandomBytes(size, [callback])`](https://nodejs.org/dist/latest-v9.x/docs/api/crypto.html#crypto_crypto_randombytes_size_callback), используя доступную энтропию, предоставляемую системой. + +**Иначе:** При создании псевдослучайных строк без криптографически безопасных методов злоумышленники могут прогнозировать и воспроизводить сгенерированные результаты, делая ваше приложение небезопасным + +

+ +Далее мы перечислили несколько важных советов от проекта OWASP. + +## ![✔] OWASP A2: сломанная аутентификация + +- Требуйте MFA/2FA для важных услуг и учетных записей +- Чаще меняйте пароли и ключи доступа, включая ключи SSH. +- Применяйте политики надежных паролей как для операций, так и для управления пользователями внутри приложения ([🔗 OWASP password recommendation](https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls.22)) +- Не отправляйте и не развертывайте свое приложение с какими-либо учетными данными по умолчанию, особенно для пользователей-администраторов или внешних служб, от которых вы зависите +- Используйте только стандартные методы аутентификации, такие как OAuth, OpenID и т.д. - **избегайте** базовой аутентификации +- Ограничивайте скорость авторизации: запрещать более _X_ попыток входа в систему (включая восстановление пароля и т.д.) в период _Y_ +- При неудачном входе в систему не сообщайте пользователю, прошла ли проверка имени пользователя или пароля, просто верните общую ошибку аутентификации +- Рассмотрите возможность использования централизованной системы управления пользователями, чтобы избежать управления несколькими учетными записями на одного сотрудника (например, GitHub, AWS, Jenkins и т.д.) и воспользоваться проверенной в бою системой управления пользователями + +## ![✔] OWASP A5: нарушен контроль доступа + +- Уважайте [Принцип минимальных привилегий](https://ru.wikipedia.org/wiki/Принцип_минимальных_привилегий) - каждый компонент и сотрудник DevOps должны иметь доступ только к необходимой информации и ресурсам +- **Никогда** не работаю с консольной/корневой (полной привилегией) учетной записью, за исключением управления учетными записями +- Запустите все экземпляры/контейнеры от имени роли/учетной записи службы. +- Назначьте разрешения для групп, а не для пользователей. Это должно сделать управление разрешениями проще и прозрачнее для большинства случаев + +## ![✔] OWASP A6: неправильная настройка безопасности + +- Доступ к внутренним компонентам производственной среды осуществляется только через внутреннюю сеть, с использованием SSH или других способов, но _никогда_ не предоставляйте внутренние службы +- Ограничьте доступ к внутренней сети - явно указывайте, какой ресурс может получить доступ к другим ресурсам (например, политика сети или подсети). +- При использовании файлов cookie настройте его в "защищенный" режим, когда он отправляется только по SSL +- При использовании файлов cookie настройте его только для "одного сайта", чтобы только запросы с одного домена возвращали указанные файлы cookie. +- При использовании файлов cookie, предпочитайте конфигурацию "HttpOnly", которая не позволяет клиентскому JavaScript-коду получить доступ к файлам cookie. +- Защитите каждый VPC с помощью строгих и ограничительных правил доступа. +- Расставляйте приоритеты угроз, используя любое стандартное моделирование угроз безопасности, такое как STRIDE или DREAD +- Защищайтесь от DDoS-атак с использованием балансировщиков нагрузки HTTP(S) и TCP. +- Проводите периодические тесты на проникновение специализированными агентствами. + +##! [✔] OWASP A3: раскрытие конфиденциальных данных + +- Принимайте только соединения SSL/TLS, применяйте Strict-Transport-Security с использованием заголовков. +- Разделите сеть на сегменты (то есть подсети) и убедитесь, что у каждого узла есть наименее необходимые разрешения на доступ к сети. +- Сгруппируйте все службы/экземпляры, которым не нужен доступ в Интернет, и явно запретите любое исходящее соединение (a.k.a частная подсеть) +- Храните все секреты в таких хранилищах, как AWS KMS, HashiCorp Vault или Google Cloud KMS. +- Блокируйте чувствительные метаданные экземпляра с использованием метаданных +- Шифруйте данные при передаче, когда они покидают физическую границу +- Не включайте секреты в записи журнала +- Избегайте показа простых паролей во внешнем интерфейсе, примите необходимые меры в бэкэнде и никогда не храните конфиденциальную информацию в открытом виде + +## ![✔] OWASP A9: использование компонентов с известными уязвимостями безопасности + +- Сканируйте образы докеров на наличие известных уязвимостей (с помощью Docker и других поставщиков, предлагающих услуги сканирования) +- Включите автоматическое исправление и обновление экземпляра (компьютера), чтобы избежать запуска старых версий ОС, в которых отсутствуют исправления безопасности. +- Предоставьте пользователю токены "id", "access" и "refresh", чтобы токен доступа был недолговечным и обновлялся токеном обновления +- Регистрируйте и проверяйте каждый вызов API для облачных сервисов и служб управления (например, кто удалил корзину S3?), Используя такие сервисы, как AWS CloudTrail. +- Запустите проверку безопасности вашего облачного провайдера (например, советник по безопасности AWS) + + +## ![✔] OWASP A10: недостаточная регистрация и мониторинг + +- Оповещайте о значительных или подозрительных событиях аудита, таких как вход пользователя в систему, создание нового пользователя, изменение разрешения и т.д. +- Оповещайте о нерегулярном количестве неудачных попыток входа в систему (или эквилантировании действий, таких как забытый пароль) +- Включайте в лог время и имя пользователя, который инициировал обновление в каждой записи БД + +## ![✔] OWASP A7: межсайтовый скриптинг (XSS) + +- Используйте шаблоны или фреймворки, которые автоматически выходят из XSS, такие как EJS, Pug, React или Angular. Изучите ограничения каждого механизма защиты XSS и соответствующим образом обработайте случаи использования, которые не охвачены +- Экранируйте ненадежные данные HTTP-запроса на основе контекста в выводе HTML (тело, атрибут, JavaScript, CSS или URL), который устранит уязвимости отраженного и хранимого XSS +- Применение контекстно-зависимых кодировок при изменении документа браузера на стороне клиента действует против DOM XSS +- Включайте политики защиты контента (CSP) в качестве средства защиты от XSS для смягчения защиты. + + +