Памятка по безопасности для веб-разработчиков

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

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

После того, как вы просмотрите приведённый ниже контрольный список задач, которые нужно решить для обеспечения безопасности веб-проекта, вы, наверняка, сами увидите, что многое из того, что в нём есть, в вашей разработке не учтено. Что делать? Как минимум — будьте честны с потенциальными пользователями и сообщите им о том, что ваш проект пока находится в стадии разработки, что вы предлагаете им ознакомиться с прототипом, в котором пока не реализована полноценная система безопасности.

Базы данных

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

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

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

• Храните и передавайте данные учётных записей, токены доступа к системе и прочую секретную информацию, используя хранилище ключей, рассчитанное на подобные сценарии работы. Не храните такие данные, жёстко задав их в коде приложений.

• Защитите систему от атак путём SQL-инъекций, используя только подготовленные SQL-запросы. Например, если ваш проект рассчитан на Node.js, не применяйте nmp-библиотеку mysql, обратитесь к библиотеке mysql2, которая поддерживает подготовленные запросы.

Разработка

• Обеспечьте проверку компонентов системы на уязвимости перед каждым релизом. Речь идёт обо всех библиотеках, пакетах, о рабочей среде. В идеале, проверки надо автоматизировать в рамках процесса CI-CD.

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

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

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

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

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

• Применяйте, для всех сервис-провайдеров, многофакторную аутентификацию.

Защита от DOS-атак

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

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

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

Веб-трафик

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

• Куки-файлы должны иметь атрибут httpOnly, они должны быть защищёнными, среди их атрибутов должны присутствовать параметры path и domain.

• Используйте политику защиты контента (CSP, Content Security Policy), не давая разрешений unsafe-inline и unsafe-eval. Такую политику непросто настроить, но это стоит затраченных сил и времени. Применяйте механизм Subresource Integrity для CDN-контента.

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

• Применяйте механизм HSTS для обеспечения доступа к системе только с помощью TLS. Не доверяйте клиентским системам, обеспечьте использование HTTPS на стороне сервера.

• Используйте CSRF-токены во всех формах, применяйте новый атрибут куки-файлов SameSite для защиты от CSRF-атак. Его поддерживают современные версии браузеров.

API

• Проверьте, чтобы в общедоступных API не было ресурсов, которые можно обнаружить методом перебора.

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

Проверка и преобразование данных

• Проверяйте, на стороне клиента, данные, введённые пользователями. Это позволит им быстрее получить отклик на свои действия. Однако, никогда не доверяйте этой проверке. Всегда проверяйте и преобразуйте к необходимому вам формату то, что ввёл пользователь, перед отображением на страницах сайта.

• Проверяйте всё, что поступает от пользователя, используя белые списки на сервере. Никогда не вставляйте незакодированные данные, введённые пользователем, в HTTP-запросы и ответы. Ни при каких обстоятельствах не используйте потенциально опасные данные, введённые пользователем, в SQL-запросах или в другой серверной логике.

Настройки облачной среды

• Проверьте, чтобы у всех облачных сервисов было открыто минимальное количество портов. Хотя обеспечение безопасности через сокрытие информации — это не защита, использование нестандартных портов усложнит жизнь тем, кто попытается атаковать вашу систему.

• Держите базы данных и службы в виртуальных частных облаках (VPС, Virtual Private Cloud) к которым нет доступа извне. Будьте очень внимательны, конфигурируя группы безопасности AWS и настраивая пиринг между VPC, так как ошибки могут привести к тому, что внутренние сервисы будут видны извне.

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

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

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

• Всегда используйте роли AWS IAM, а не учётную запись суперпользователя.

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

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

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

• Убедитесь в том, что можете выполнять обновления проекта без простоев. Внедрите полностью автоматическую систему, которая позволяет быстро обновлять ПО.

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

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

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

• Не держите постоянно открытым порт 22 в любой группе сервисов AWS. Если вам совершенно необходим доступ по SSH, используйте только аутентификацию с открытым ключом, а не логины и пароли.

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

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

Эксплуатация инфраструктуры

• Отключайте неиспользуемые сервисы и сервера. Самый защищённый сервер — это тот, из которого выдернули шнур питания.

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

• Выполняйте аудит архитектуры и реализации системы.

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

Обучение персонала

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

План действий во внештатной ситуации

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

• Подготовьте чёткий план действий во нештатной ситуации. Однажды он вам понадобится.

Итоги

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

То, что вы прочли, основано на более чем четырнадцатилетнем опыте автора материала в сфере разработки защищённых веб-приложений. Этот опыт дался ему нелегко, и мы уверены, что его находки смогут облегчить жизнь тем, кого беспокоит безопасность их веб-решений.