Перевод статьи о том, как защитить ваш веб-сервис от злоумышлеников от Michael O’Brien.

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

Если вы целиком доверились идее MVP и считаете, что сможете создать за один месяц безопасный и ценный продукт, подумайте дважды над его запуском. После того, как ознакомитесь с списком ниже, поймите что сохраняете множество из описанных изъянов в безопасности вашего сервиса. Как минимум будьте честны с собой и со своимим потенциальными пользователями и оповестите их, что предлагаете им прототип, который не обеспечивает полноценную безопасность.

Этот список прост и отнудь не полон. Занимаясь веб разработкой последние 14 лет я собрал в него самые важные и болезненные уроки, которые получил в процессе. Надеюсь, вы примете его серьезно, когда будете заниматься своим проектом.

Пожалуйста оповестите, если вам есть, что добавить в список.

База данных

• Используйте шифрование для данных идентифицирующих пользователей и остальной чувствительной информации (токены, электронная почта, данные по биллингу).

• Если ваша СУБД поддерживает не дорогое шифрование хранящихся данных, включите его. Так же убедитесь, что все резервные копии так же зашифрованы.

• Максимально ограничьте в правах пользователя с доступом к БД. Не используйте root и проверяйте наличие лишних аккаунтов, так же как и аккаунтов с слабым паролем.

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

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

Разработка

• Убедитесь что все версии каждого компонента вашей программы, проверены на уязвимости. Это может быть автоматизированно в CI-CD.

• Обеспечьте сервисам процесса разработки такую же безопасность, как продакшену.

Авторизация

• Убедитесь, что все пароли хешируются с использованием надежных криптоалгоритмов, таких как bcrypt. Никогда не разрабатывайте свои собственные алгоритмы шифрования и правильно инициализируйте существующие алгоритмы случайными данными. Используйте best-practices и компоненты, которые прошли проверку временем для авторизации, востановления пароля итд. Не изобретайте велосипед - очень тяжело протестировать его на всех возможных ситуациях.

• Введите простые, но адекватные, правила для паролей, которые стимулируют пользователей делать их длинными и сложными.

• Используйте многофакторную авторизацию для доступа к поставщикам услуг.

Защититесь от DoS

• Удостоверьтесь что DoS атаки на ваш API не нанесут урона вашему сервису. Как минимум, установите ограничители на медленные методы и API для работы с авторизацией. Включите капчу на фронтэнде, чтобы защитить серверсайд от DoS атак.

• Введите разумные фильтры на размер и структуру запросов и данных, получаемых от пользователя.

• Рассматривайте сервисы с кеширующим прокси для смягчения последствий DDoS атак. Их можно включать на время атак, а в остальное время использовать как DNS сервер.

Траффик

• Используйте TLS на всем сайте. Никогда не включайте TLS отдельно для форм авторизации. По-хорошему используйте strict-transport-security заголовок, чтобы принудительно использовать HTTPS для всех запросов.

• Cookies должны быть httpOnly и ограничены путем и доменом.

• Используйте Content Security Policy без правил с *. Тяжело настроить, но оно того стоит. Используйте CSP Subresource Integrity для содержимого из CDN.

• X-Frame-Option и X-XSS-Protection должны быть добавленые в заголовки для ответов. Используйте https://observatory.mozilla.org для проверки сайта.

• Воспользуйтесь HSTS для того, чтобы принудительно давать доступ только по TLS. Перенаправляйте все HTTP запросы на HTTPS на сервере для надежности.

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

API

• Убедитесь, что ваши сущности нельзя перебрать с помощью вашего публичного API.

• Удостоверьтесь, что пользователи полностью авторизованы и у них есть права для использования методов.

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

Валидация и кодирование

• Проверяйте все вводимые данные на стороне клиента, для быстрого фидбека юзеру, но не доверяйте им полностью.

• Валидируйте каждый бит вводимой пользователем информации используя белые списки на сервере. Никогда не добавляйте пользовательский ввод в ответы напрямую. Никогда не используйте не проверенные данные в SQL выражениях и другой логике.

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

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

• Хостите сервисы и базы данных на приватных VPC, которые не видимы из публичных сетей. Будьте осторожны, когда настраиваете группы безопасности в AWS и коммуникацию между VPC, чтобы случайно не сделать их видимыми из публичной сети.

• Изолируйте сервисы в отдельных VPCs и используйте приватную сеть для межсервисной коммуникации.

• Фильтруйте адреса с которых сервисы будут принимать запросы.

• Ограничьте исходящий трафик по адресам и портам, чтобы уменьшить вероятность попадания в ботнет.

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

• Ограничьте права всех разработчиков и администраторов до минимально необходимых для выполнения своей работы.

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

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

• Постарайтесь при обновлении минимизировать downtime. Убедитесь, что процесс обновления полностью автоматизирован.

• Создайте всю инфраструктуру в утилите типа Terraform. Она должны быть представлена в виде кода и все должно подниматься по нажатию кнопки. Старайтесь не использовать ресурсы созданные из консоли облака.

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

• Используйте SSH только в редких случаях. Частое подключение по SSH говорит о том, что вы не автоматизировали что-то важное.

• Не держите 22 порт постоянно открытым. Так же, если вам необходим SSH, подключайтесь с помощью PKA, а не паролей.

• Поднимайте неизменяемые хосты, вместо серверов долгожителей которые вы постоянно патчите и обновляете.

• Используйте IDS - системы определения вторжения.

Работа

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

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

• Проводите аудит вашей архитектуры и ее имплементации в коде.

• Проводите тесты на проникновение - пытайтесь взломать себя. Так же хорошо если пентестом будет заниматься кто-то еще кроме вас.

Обучение

• Объясняйте вашим работникам опасности и техники используемые в социальной инженерии.

Наконец, имейте план действий

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

• Имейте готовый план действий, на случай атаки. Однажды он может пригодиться.

Оригинал: https://medium.com/simple-security/web-developer-security-checklist-f2e4f43c9c56
Github: https://github.com/virajkulkarni14/WebDeveloperSecurityChecklist