🌐 Чек листы безопасности для веб-разработчика — Information Security Squad
🌐 Чек листы безопасности для веб-разработчика

Разрабатывать безопасные и надежные веб-приложения в облаке сложно, очень сложно.

Если вы думаете, что это легко, вы либо высшая форма жизни, либо у вас впереди болезненное пробуждение.

Если вы запускаете MVP и считаете, что можете создать продукт за один месяц, который будет ценным и безопасным, подумайте дважды, прежде чем запускать свой «протопродукт».

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

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

Этот контрольный список прост и ни в коем случае не полон.

Я надеюсь, что вы будете серьезно их учитывать при создании веб-приложения.

Пожалуйста, прокомментируйте, если у вас есть какие-либо пункты, которые можно добавить в этот список.

База данных

[ ] Используйте шифрование для данных, идентифицирующих пользователей и конфиденциальные данныех, таких как токены доступа, адреса электронной почты или платежные данные.

[ ] Если ваша база данных поддерживает шифрование в состоянии покоя (например, AWS Aurora), включите его для защиты данных на диске. Убедитесь, что все резервные копии хранятся в зашифрованном виде.

 [] Используйте минимальные привилегии для учетной записи пользователя для доступа к базе данных. Не используйте учетную запись root для базы данных.

[ ] Храните и распространяйте секреты, используя хранилище ключей, предназначенное для таких целей, как Vault или AWS Secret Manager. Не создавайте секретных кодов в своих приложениях и НИКОГДА не храните секреты в GitHub.

[ ] Полностью предотвратите  SQL инъекцию, используя только подготовленные операторы SQL. Например: если вы используете NPM, не используйте npm-mysql, используйте npm-mysql2, который поддерживает подготовленные операторы.

Развертка

[ ] Убедитесь, что все компоненты вашего программного обеспечения проверены на наличие уязвимостей для каждой версии, переданной в производство. Это включает в себя O/S, библиотеки и пакеты. Это должно быть автоматизировано в процессе CI/CD.

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

Аутентификация

[ ] Убедитесь, что все пароли хешируются с использованием соответствующего алгоритма шифрования, такого как bcrypt. Никогда не пишите свую собственную крипту и правильно инициализируйте ее.

[ ] Внедрите простые, но адекватные правила для паролей, которые будут заставлять пользователей использовать длинные случайные пароли.

[ ] Используйте многофакторную аутентификацию для входа в систему всем вашим поставщикам служб.

Защита от отказа в обслуживании

[ ] Убедитесь, что атаки DOS на ваши API не нанесут вред вашему сайту. Как минимум, установите ограничения скорости на API, таких как процедуры входа в систему и генерации токенов.

[ ] Принудительное ограничение размера и структуры данных и запросов, представленных пользователем.

[ ] Используйте смягчение распределенного отказа в обслуживании (DDOS) через глобальный прокси-сервис кеширования, такой как CloudFlare. Это может быть включено в проект, если вы подвергаетесь атаке DDOS.

Интернет-трафик

[ ] Используйте TLS для всего сайта, а не только для форм входа и ответов. Никогда не используйте TLS только для формы входа.

[ ] Файлы cookie должны быть доступны только в режиме httpOnly и быть безопасными, а также иметь область действия и путь.

[ ] Используйте CSP, не допуская небезопасных бэкдоров. Это очень сложно настроить, но стоит того.

[ ] Используйте X-Frame-Option, заголовки X-XSS-Protection в ответах клиента.

[ ] Используйте ответы HSTS для принудительного доступа только по TLS. Перенаправьте все HTTP-запросы на HTTPS на сервере в качестве резервной копии.

[ ] Используйте токены CSRF во всех формах и используйте новый заголовок ответа SameSite Cookie, который исправляет CSRF и для всех новых браузеров.

API-интерфейсы

[ ] Убедитесь, что в ваших общедоступных API нет перечисляемых ресурсов.

[ ] Убедитесь, что пользователи полностью аутентифицированы и авторизованы соответствующим образом при использовании ваших API.

[ ] Используйте проверки в API для обнаружения незаконных или ненормальных запросов, которые указывают на атаки.

Проверки

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

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

Конфигурация облака

[ ] Убедитесь, что все сервисы имеют минимальное число открытых портов. Хотя безопасность через неизвестность не является защитой, использование нестандартных портов усложнит задачу для злоумышленников.

[ ] Организуйте хостинг базы данных и сервисов на частных VPC, которые не видны ни в одной общедоступной сети. Будьте очень осторожны при настройке групп безопасности AWS и пиринговых VPC, которые могут непреднамеренно сделать службы видимыми для общественности.

[ ] Изолировать логические сервисы в отдельных VPC и одноранговых VPC, чтобы обеспечить межсервисную связь.

[ ] Убедитесь, что все службы принимают данные только с минимального набора IP-адресов.

[ ] Ограничьте исходящий IP и трафик портов, чтобы минимизировать APT и «botification».

[ ] Всегда используйте пользователей и роли AWS IAM, а не учетные данные root. Инвестируйте в обучение эффективному использованию IAM.

[ ] Используйте минимальные права доступа для всех сотрудников и разработчиков. Предоставьте пользователям и ролям IAM минимальные возможности, необходимые для выполнения задачи.

[ ] Регулярно меняйте пароли и ключи доступа по заданому расписанию.

Инфраструктура

[ ] Убедитесь, что вы можете делать обновления без простоев. Убедитесь, что вы можете быстро обновить программное обеспечение полностью автоматизированным способом.

[ ] Создайте всю инфраструктуру, используя такой инструмент, как Terraform, а не через облачную консоль. Инфраструктура должна быть определена как «код» и может быть воссоздана одним нажатием кнопки. Не переносите на дух любой ресурс, созданный в облаке вручную — Terraform может затем проверить вашу конфигурацию.

[ ] Используйте централизованное ведение журнала для всех служб. Вам никогда не потребуется SSH для доступа или получения журналов.

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

[ ] Не оставляйте порт 22 открытым для каких-либо сервисных групп AWS на постоянной основе.

[ ] Создайте неизменные хосты вместо долгоживущих серверов, которые вы исправляете и обновляете.

[ ] Используйте систему обнаружения вторжений, чтобы минимизировать APT.

Операции

[ ] Отключите неиспользуемые сервисы и серверы. Самый безопасный сервер — это тот, который выключен. Это можно запланировать с помощью таких инструментов, как PowerDown.

Тестирование

[ ] Аудит вашего дизайна и реализации.

[ ] Пройдите тестирование на проникновение — взломайте себя, но также еще попросите кого-нибудь провести тестирование.

Наконец, составьте план

[ ] Разработайте модель угрозы, которая описывает, от чего вы защищаетесь. Она должна перечислить и расставить приоритеты возможных угроз и субъектов.

[] Разработайте практический план по обработке инцидентов безопасности. Однажды он вам понадобится.

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *