Если вы проектируете, создаете, тестируете ваше веб-приложение/мобильное приложение с учетом безопасности, этот контрольный список встречных мер может быть хорошей отправной точкой
Системы аутентификации (регистрация/Signin/2 фактор/сброс пароля)
Используйте HTTPS везде.
Храните хэши с паролем с использованием Bcrypt (не требуется соль - Bcrypt делает это для вас).
Уничтожьте идентификатор сеанса после logout .
Уничтожьте все активные сеансы при сбросе пароля (или предложите).
Должен иметь параметр state в OAuth2.
Нет открытых перенаправлений после успешного входа в систему или в каких -либо других промежуточных перенаправлениях.
При анализе регистрации/ввода входа в систему дезинфицируется для JavaScript: //, data: //, символы CRLF.
Установите безопасное, httponly cookie.
В мобильной мобильной проверке на основе OTP не отправляйте OTP обратно в ответ при generate OTP или Resend OTP API.
Ограничить попытки Login , Verify OTP , Resend OTP и generate OTP для конкретного пользователя. Имейте экспоненциальный набор отборов или/и что -то вроде вызова на основе CAPTCHA.
Проверьте случайность сброса токена пароля в ссылке по электронной почте или SMS.
Установите истечение срока действия токена сброса пароля в течение разумного периода.
Срок действия сброса токена сброса после того, как он был успешно использован.
Пользовательские данные и авторизация
Любой доступ к ресурсам, как, my cart , my history должна проверить зарегистрированное в собственности пользователя на ресурс с помощью идентификатора сеанса.
Следует избегать идентификационного идентификатора ресурса. Используйте /me/orders вместо /user/37153/orders . Это действует как проверка здравомыслия на случай, если вы забыли проверить наличие токена авторизации.
Edit email/phone number должна сопровождаться проверкой электронной почты владельцу учетной записи.
Любая функция загрузки должна дезинфицировать имя файла, предоставленное пользователем. Кроме того, по причинам, помимо безопасности, загружайте в что-то вроде S3 (и пост-процесс с использованием Lambda), а не на ваш собственный сервер, способный выполнять код.
Функция Profile photo upload должна дезинфицировать все теги EXIF также, если не требуется.
Для идентификаторов пользователей и других идентификаторов используйте RFC -соответствующий UUID вместо целых чисел. Вы можете найти реализацию для этого для вашего языка на GitHub.
JWT потрясающие. Используйте их, если это необходимо, для вашего приложения/APIS с одной страницей.
База данных
Используйте шифрование для идентификации пользователей данных, а также конфиденциальные данные, такие как токены доступа, адреса электронной почты или сведения о выставлении счетов.
Если ваша база данных поддерживает недорогие шифрование в состоянии покоя (например, AWS Aurora), тогда включите, чтобы получить данные на диске. Убедитесь, что все резервные копии также хранятся зашифрованы.
Используйте минимальную привилегию для учетной записи пользователя Batabase Access. Не используйте корневую учетную запись базы данных.
Храните и распространите секреты, используя магазин ключей, разработанный для этой цели. Не жесткий код в ваших приложениях.
Полностью предотвратите инъекцию SQL, только с помощью SQL -подготовленных операторов. Например: при использовании NPM не используйте NPM-MYSQL, используйте NPM-MySQL2, который поддерживает подготовленные операторы.
Приложение Android / iOS
salt из платежных шлюзов не должна быть жесткой.
secret / auth token от сторонних SDK не должен быть жестко.
Вызовы API, предназначенные для выполнения server to server не должны быть сделаны из приложения.
В Android все предоставленные разрешения должны быть тщательно оценены.
На iOS хранить конфиденциальную информацию (токены аутентификации, клавиши API и т. Д.) В системном ключевом режиме. Не храните такую информацию в по умолчаниях пользователя.
Сертификат настоятельно рекомендуется.
Заголовки и конфигурации безопасности
Add заголовок CSP, чтобы смягчить XSS и атаки впрыска данных. Это важно.
Add заголовок CSRF, чтобы предотвратить подделку подделки по перекрестному участку. Также добавьте атрибуты SameSite в файлы cookie.
Add заголовок HSTS, чтобы предотвратить атаку SSL.
Add свой домен в список предварительных нагрузков HSTS
Add x-frame-options, чтобы защитить от клика.
Add заголовок X-XSS-защиты, чтобы смягчить атаки XSS.
Обновите записи DNS, чтобы добавить записи SPF, чтобы смягчить спам и фишинговые атаки.
Добавьте проверки целостности Subresource, при загрузке ваших библиотек JavaScript из стороннего CDN. Для дополнительной безопасности добавьте требование-Sri-For CSP-диративное, чтобы вы не загружали ресурсы, которые не имеют SRI SAT.
Используйте случайные токены CSRF и разоблачайте API бизнес -логики в качестве запросов HTTP Post. Не выставляйте токены CSRF через HTTP, например, на начальном этапе обновления запроса.
Не используйте критические данные или токены в параметрах запроса GET. Экспозиция журналов сервера или обработка их машины/стека по очереди будет обнаружена пользовательскими данными по очереди.
Проантизация ввода
Sanitize все пользовательские входы или любые входные параметры, подвергнутые пользователю, для предотвращения XSS.
Всегда используйте параметризованные запросы, чтобы предотвратить инъекцию SQL.
Дезинфицировать пользовательский ввод, если он использует его непосредственно для функциональных возможностей, таких как импорт CSV.
Sanitize пользовательский ввод для особых случаев, таких как robots.txt в качестве имен профилей, если вы используете шаблон URL, такой как CoolCorp.io/username.
Не вручите код и не строите JSON по струнной конкатенации, независимо от того, насколько маленьким является объект. Используйте свой язык, определенные библиотеками или структурой.
Дезинфицировать входные данные, которые принимают какие -то URL -адреса, чтобы предотвратить SSRF.
Дезинфицировать выходы перед отображением пользователям.
Отказ в защите обслуживания
Убедитесь, что атаки DOS на ваши API не нанесли ущерб вашему сайту. Как минимум, имейте ограничители скорости на ваших более медленных путях API, такие как входные и генеральные процедуры. Рассмотрим Captcha на Front-End API, чтобы защитить услуги от DOS.
Обеспечение пределов здравомыслия по размеру и структуре предоставленных пользовательскими данными и запросами.
Используйте смягчение распределенного отказа в обслуживании (DDOS) с помощью глобального прокси -сервиса кэширования, таких как CloudFlare. Это можно включить, если вы страдаете от атаки DDOS и в противном случае функционируют как ваш поиск DNS.
Операции
Если вы маленькие и неопытные, оцените использование AWS Elasticbeanstalk или PaaS для запуска вашего кода.
Используйте приличный сценарий для создания виртуальных машин в облаке.
Проверьте машины с нежелательными публичными open ports .
Проверьте наличие паролей NO/по умолчанию для databases , особенно MongoDB и Redis.
Используйте SSH для доступа к вашим машинам; Не настраивайте пароль, вместо этого используйте аутентификацию на основе ключей SSH.
Установите обновления своевременно, чтобы действовать на уязвимости нулевого дня, такие как Heartbleed, Shellshock.
Измените конфигурацию сервера, чтобы использовать TLS 1.2 для HTTPS и отключить все другие схемы. (Компромисс хорош.)
Не оставляйте режим отладки. В некоторых структурах режим отладки может предоставить доступную полноценную реплику или оболочки или выявлять критические данные в сообщениях об ошибках.
Будьте готовы к плохим актерам и DDOS - используйте хостинг -сервис, который имеет смягчение DDOS.
Установите мониторинг для ваших систем и журнал (используйте новую реликвию или что -то в этом роде).
Если разработка для корпоративных клиентов, придерживайтесь требований соответствия. Если AWS S3, рассмотрите возможность использования функции для шифрования данных. Если использовать AWS EC2, рассмотрите возможность использования функции для использования зашифрованных объемов (даже теперь могут быть зашифрованы объемы загрузки).
Облачная конфигурация
Убедитесь, что все услуги имеют минимальные порты. В то время как безопасность через безвестность не является защитой, использование нестандартных портов сделает его немного сложнее для злоумышленников.
База данных и сервисы Host Backend на частных VPC, которые не видны в какой -либо публичной сети. Будьте очень осторожны при настройке групп безопасности AWS и вставки VPC, которые могут непреднамеренно сделать услуги видимыми для общественности.
Выделите логические услуги в отдельных VPC и одноранговых VPC, чтобы обеспечить межпроводную связь.
Убедитесь, что все услуги принимают данные только из минимального набора IP -адресов.
Ограничить исходящий IP и порт трафик, чтобы минимизировать APT и «ботификацию».
Всегда используйте роли AWS IAM, а не корневые учетные данные.
Используйте минимальную привилегию доступа для всех OPS и сотрудников разработчиков.
Регулярно поверните пароли и клавиши доступа в соответствии с расписанием.
CI & CD Audit Your Design и реализация с помощью конфиденциальных тестов на модуль/интеграции. Используйте процесс проверки кода и игнорируйте самооценку. Убедитесь, что все компоненты ваших услуг статически сканируются AV Software, прежде чем выдвигать производство, включая библиотеки поставщиков и другие зависимости. Разработайте решение для развертывания.
ЛЮДИ
Настройте электронное письмо (например, [email protected]) и страницу для исследователей безопасности, чтобы сообщить об уязвимости.
В зависимости от того, что вы делаете, ограничивайте доступ к вашим базам данных пользователей.
Будьте вежливы для журналистов.
Сделайте ваш обзор кода другим разработчиком с точки зрения безопасного кодирования. (Больше глаз)
В случае взлома или нарушения данных проверьте предыдущие журналы для доступа к данным, попросите людей изменить пароли. Вам может потребоваться аудит внешних агентств в зависимости от того, где вы включены.
Инфраструктура
Убедитесь, что вы можете сделать обновления без простоя. Убедитесь, что вы можете быстро обновить программное обеспечение полностью автоматизированным образом.
Создайте всю инфраструктуру, используя такой инструмент, как Terraform, а не через облачную консоль. Инфраструктура должна быть определена как «код» и быть в состоянии воссоздан на нажатию кнопки. Иметь нулевую толерантность к любому ресурсу, созданному в облаке вручную - Terraform может затем проверить вашу конфигурацию.
Используйте централизованный журнал для всех услуг. Вам никогда не нужно SSH для доступа или получения журналов.
Не входите на услуги, кроме разовой диагноза. Использование SSH регулярно, как правило, означает, что вы не автоматизировали важную задачу.
Не держите порт 22 открытым на каких -либо сервисных группах AWS на постоянной основе. Вместо этого подумайте о том, чтобы разрешить только уполномоченные IPS SSH на коробке.
Создайте неизменные хосты вместо долгоживущих серверов, которые вы исправляете и обновляете. (См. Необрестимая инфраструктура может быть более безопасной).
Используйте систему обнаружения вторжений, такую как Sensedeep или Service, чтобы минимизировать APT.
