Раздел общих рекомендаций по безопасности содержит рекомендации, которые стандартизированы во многих платформах и соглашениях, например, запуск приложения с SSL/TLS должен быть общим руководством и соглашением, которое следует соблюдать при каждой настройке для достижения значительных преимуществ безопасности.
TL;DR: Во времена бесплатных SSL/TLS-сертификатов и их простой настройки вам больше не нужно взвешивать преимущества и недостатки использования безопасного сервера, потому что такие преимущества, как безопасность, поддержка современных технологий и доверие, явно перевешивают такие недостатки, как минимальные издержки по сравнению с чистым HTTP.
Иначе: Злоумышленники могут выполнять атаки "человек посередине", следить за поведением ваших пользователей и совершать еще более злонамеренные действия, когда соединение не зашифровано.
🔗 Read More: Запуск безопасного Node.js сервера
TL;DR: При сравнении секретных значений или хэшей, таких как код HMAC, вы должны использовать crypto.timingSafeEqual(a, b) функция Node обеспечивает готовую работу, начиная с Node.js v6.6.0. Этот метод сравнивает два заданных объекта и продолжает сравнивать, даже если данные не совпадают. Методы сравнения равенства по умолчанию просто возвращались бы после несоответствия символов, позволяя рассчитывать время атаки на основе длины операции.
Иначе: Используя операторы сравнения равенства по умолчанию, вы можете предоставить критическую информацию, основываясь на времени, затраченном на сравнение двух объектов.
TL;DR: Использование специально созданной функции, генерирующей псевдослучайные строки для токенов и других чувствительных к безопасности случаев использования, на самом деле может быть не таким случайным, как вы думаете, что делает ваше приложение уязвимым для криптографических атак. Когда вам нужно создать безопасные случайные строки, используйте crypto.randomBytes(size, [callback]), используя доступную энтропию, предоставляемую системой.
Иначе: При создании псевдослучайных строк без криптографически безопасных методов злоумышленники могут прогнозировать и воспроизводить сгенерированные результаты, делая ваше приложение небезопасным
Далее мы перечислили несколько важных советов от проекта OWASP.
- Требуйте MFA/2FA для важных услуг и учетных записей
- Чаще меняйте пароли и ключи доступа, включая ключи SSH.
- Применяйте политики надежных паролей как для операций, так и для управления пользователями внутри приложения (🔗 OWASP password recommendation)
- Не отправляйте и не развертывайте свое приложение с какими-либо учетными данными по умолчанию, особенно для пользователей-администраторов или внешних служб, от которых вы зависите
- Используйте только стандартные методы аутентификации, такие как OAuth, OpenID и т.д. - избегайте базовой аутентификации
- Ограничивайте скорость авторизации: запрещать более X попыток входа в систему (включая восстановление пароля и т.д.) в период Y
- При неудачном входе в систему не сообщайте пользователю, прошла ли проверка имени пользователя или пароля, просто верните общую ошибку аутентификации
- Рассмотрите возможность использования централизованной системы управления пользователями, чтобы избежать управления несколькими учетными записями на одного сотрудника (например, GitHub, AWS, Jenkins и т.д.) и воспользоваться проверенной в бою системой управления пользователями
- Уважайте Принцип минимальных привилегий - каждый компонент и сотрудник DevOps должны иметь доступ только к необходимой информации и ресурсам
- Никогда не работаю с консольной/корневой (полной привилегией) учетной записью, за исключением управления учетными записями
- Запустите все экземпляры/контейнеры от имени роли/учетной записи службы.
- Назначьте разрешения для групп, а не для пользователей. Это должно сделать управление разрешениями проще и прозрачнее для большинства случаев
- Доступ к внутренним компонентам производственной среды осуществляется только через внутреннюю сеть, с использованием 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.
- Блокируйте чувствительные метаданные экземпляра с использованием метаданных
- Шифруйте данные при передаче, когда они покидают физическую границу
- Не включайте секреты в записи журнала
- Избегайте показа простых паролей во внешнем интерфейсе, примите необходимые меры в бэкэнде и никогда не храните конфиденциальную информацию в открытом виде
- Сканируйте образы докеров на наличие известных уязвимостей (с помощью Docker и других поставщиков, предлагающих услуги сканирования)
- Включите автоматическое исправление и обновление экземпляра (компьютера), чтобы избежать запуска старых версий ОС, в которых отсутствуют исправления безопасности.
- Предоставьте пользователю токены "id", "access" и "refresh", чтобы токен доступа был недолговечным и обновлялся токеном обновления
- Регистрируйте и проверяйте каждый вызов API для облачных сервисов и служб управления (например, кто удалил корзину S3?), Используя такие сервисы, как AWS CloudTrail.
- Запустите проверку безопасности вашего облачного провайдера (например, советник по безопасности AWS)
- Оповещайте о значительных или подозрительных событиях аудита, таких как вход пользователя в систему, создание нового пользователя, изменение разрешения и т.д.
- Оповещайте о нерегулярном количестве неудачных попыток входа в систему (или эквилантировании действий, таких как забытый пароль)
- Включайте в лог время и имя пользователя, который инициировал обновление в каждой записи БД
- Используйте шаблоны или фреймворки, которые автоматически выходят из XSS, такие как EJS, Pug, React или Angular. Изучите ограничения каждого механизма защиты XSS и соответствующим образом обработайте случаи использования, которые не охвачены
- Экранируйте ненадежные данные HTTP-запроса на основе контекста в выводе HTML (тело, атрибут, JavaScript, CSS или URL), который устранит уязвимости отраженного и хранимого XSS
- Применение контекстно-зависимых кодировок при изменении документа браузера на стороне клиента действует против DOM XSS
- Включайте политики защиты контента (CSP) в качестве средства защиты от XSS для смягчения защиты.