nodebestpractices/sections/security/commonsecuritybestpractices.russian.md

[✔]: ../../assets/images/checkbox-small-blue.png

# Общие рекомендации по безопасности Node.js

Раздел общих рекомендаций по безопасности содержит рекомендации, которые стандартизированы во многих платформах и соглашениях, например, запуск приложения с SSL/TLS должен быть общим руководством и соглашением, которое следует соблюдать при каждой настройке для достижения значительных преимуществ безопасности.

## ![✔] Используйте SSL/TLS для шифрования соединения клиент-сервер

**TL;DR:** Во времена [бесплатных SSL/TLS-сертификатов](https://letsencrypt.org/) и их простой настройки вам больше не нужно взвешивать преимущества и недостатки использования безопасного сервера, потому что такие преимущества, как безопасность, поддержка современных технологий и доверие, явно перевешивают такие недостатки, как минимальные издержки по сравнению с чистым HTTP.

**Иначе:** Злоумышленники могут выполнять атаки "человек посередине", следить за поведением ваших пользователей и совершать еще более злонамеренные действия, когда соединение не зашифровано.

🔗 [**Read More: Запуск безопасного Node.js сервера**](./secureserver.russian.md)

<br/><br/>

## ![✔] Безопасное сравнение секретных значений и хэшей

**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. Этот метод сравнивает два заданных объекта и продолжает сравнивать, даже если данные не совпадают. Методы сравнения равенства по умолчанию просто возвращались бы после несоответствия символов, позволяя рассчитывать время атаки на основе длины операции.

**Иначе:** Используя операторы сравнения равенства по умолчанию, вы можете предоставить критическую информацию, основываясь на времени, затраченном на сравнение двух объектов.

<br/><br/>

## ![✔] Генерация случайных строк с использованием Node.js

**TL;DR:** Использование специально созданной функции, генерирующей псевдослучайные строки для токенов и других чувствительных к безопасности случаев использования, на самом деле может быть не таким случайным, как вы думаете, что делает ваше приложение уязвимым для криптографических атак. Когда вам нужно создать безопасные случайные строки, используйте [`crypto.randomBytes(size, [callback])`](https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback), используя доступную энтропию, предоставляемую системой.

**Иначе:** При создании псевдослучайных строк без криптографически безопасных методов злоумышленники могут прогнозировать и воспроизводить сгенерированные результаты, делая ваше приложение небезопасным

<br/><br/>

Далее мы перечислили несколько важных советов от проекта 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 для смягчения защиты.


<br/><br/><br/>