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

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


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


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


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



Базы данных


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


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


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


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


Защитите систему от атак путём 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, используйте только аутентификацию с открытым ключом, а не логины и пароли.


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


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



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


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



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


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


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



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


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



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


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


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



Итоги


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


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


Источник: habrahabr.ru


Оригинал: simplesecurity.sensedeep.com

Просмотров: 393 Комментариев: 0
Дата публикации: 2 Июня 2017, 13:50