1 июня в 12:30

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

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

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



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

Базы данных


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

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

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

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

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

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

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

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


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

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


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

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

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


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

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


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

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

Итоги


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

То, что вы прочли, основано на более чем четырнадцатилетнем опыте автора материала в сфере разработки защищённых веб-приложений. Этот опыт дался ему нелегко, и мы уверены, что его находки смогут облегчить жизнь тем, кого беспокоит безопасность их веб-решений.
Уважаемые читатели! А что бы вы добавили в этот список?
Автор: @ru_vds Michael O'Brien
RUVDS.com
рейтинг 408,41
RUVDS – хостинг VDS/VPS серверов

Комментарии (5)

  • 0
    Есть только одна вещь, которой не хватает в этой инструкции — не используйте AWS, хоститесь вместо этого в датацентрах, где вы сами контролируете, как и где хранятся данные (имеется в виду, что делать так нужно в случае, когда вы действительно хотите иметь хороший security).
  • 0
    • +2
      К сожалению, иногда так бывает с переводами, что они делаются параллельно разными людьми. Однако появление этого материала в двух местах говорит лишь о его актуальности.
  • 0
    hsts preload для первого реквеста?
  • 0
    Используйте CSRF-токены во всех формах, применяйте новый атрибут куки-файлов SameSite для защиты от CSRF-атак. Его поддерживают современные версии браузеров.

    А вот с этим проблема. На данный момент SameSite поддерживается только в Chrome и Chromium-браузерах.

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

Самое читаемое Разработка