Безопасность веб-приложений: от разработки до эксплуатации
В настоящее время существует множество методик, описывающих жизненный цикл программного обеспечения (Software Development Life Cycle), но большинство из них упоминают следующие этапы:
1. Планирование
2. Анализ
3. Проектирование
4. Разработка
5. Тестирование и интеграция
6. Эксплуатация
Комплексный поход к безопасности веб-приложений предполагает встраивание определенных процессов и инструментов на каждом этапе жизненного цикла. Применение лучших практик по безопасности предполагает тесное взаимодействие подразделений информационной безопасности (ИБ), разработки и эксплуатации. Часто такой подход называют DevSecOps (от англ. development, security и operations). В рамках всего жизненного цикла обычно декларируются следующие принципы:
· за безопасность отвечает каждый
· требования к безопасности стандартизируются
· выполнение и проверка требований ИБ максимально автоматизируются
· определяются метрики для регулярной оценки уровня защищенности
· регулярно проводится обучение по вопросам безопасности
Рассмотрим практики и инструменты, повышающие безопасность веб-приложений, на каждом из этапов жизненного цикла:
На этапе планирования ответственные за веб-приложение должны быть ознакомлены с принятыми в организации практиками и требованиями ИБ. На данном этапе нужно заложить ресурсы на реализацию этих требований, а также привлечь сотрудников подразделения ИБ для более точной оценки связанных с ними этапов: сканирование на уязвимости, журналирование, интеграция с централизованными системами аутентификации и авторизации, и т.д.
На этапе анализа рекомендуется провести моделирование угроз безопасности (threat modeling). Оно поможет сфокусироваться на актуальных и релевантных угрозах, а также грамотно распределить ресурсы на защиту. С моделированием могут помочь бесплатные инструменты, такие как OWASP Threat Dragon и Microsoft Threat Modeling Tool. Глобальным стандартом в области угроз для веба являются регулярно обновляемые списки OWASP Top 10 и OWASP API Security Top 10.
На этапе проектирования необходимо максимально подробно отразить основные компоненты веб-приложения, потоки данных и интеграции с другими системами, включая средства защиты. Также на данном этапе будет полезно нарисовать сетевую схему, которая покажет хосты, порты и протоколы взаимодействия. Описание подходов к сетевой сегментации и примеры схем можно найти в проекте Network Segmentation Cheat Sheet. Если веб-приложение использует API, то нужно заранее позаботиться о его описании, например в формате Open API Specification. Подробное документирование позволяет значительно снизить затраты на проверки безопасности на следующих этапах.
На этапе разработки веб-приложения полезными практиками, повышающими безопасность, являются статический анализ кода (Static Application Security Testing), компонентный анализ (Software Composition Analysis) и поиск секретов в исходных кодах. Существуют десятки, если не сотни, инструментов для реализации этих практик: бесплатные или коммерческие, универсальные или специализированные под конкретный язык программирования. Также не стоит забывать про создание кода, реализующего сами функции безопасности, например логирование или авторизацию. Наличие данных функций может значительно повысить защищенность веб-приложения.
На этапе тестирования и интеграции обычно выполняют сканирование на уязвимости. Для веб-приложений важной частью такого сканирования является динамическое тестирование (Dynamic Application Security Testing). Полезной техникой является фаззинг (fuzzing), который заключается в передаче приложению на вход неправильных, неожиданных или случайных данных. Для критичных веб-приложений иногда проводят тестирование на проникновение (pentest), в таких случаях обычно приглашают организации или специалистов, которые имеют профессиональный опыт в этой области. Количество проверок для веб-приложений может доходить до нескольких сотен. Выбрать нужные и не пропустить критичные поможет OWASP Web Security Testing Guide.
Этап эксплуатации является наиболее критичным с точки зрения безопасности. Веб-приложение уже доступно для клиентов и если уязвимость была пропущена на предыдущих этапах, то ее эксплуатация может привести к серьезным последствиям, таким как: компрометация инфраструктуры, утечка данных и недоступность сервиса. Чтобы адекватно реагировать на такие угрозы необходимо использовать межсетевой экран для защиты веб-приложений (Web Application Firewall) и/или специализированные решения по защите API. Кроме блокирующих правил данные инструменты генерируют множество событий безопасности, которые полезно передавать на анализ в центр информационной безопасности (Security Operations Center).
Таким образом подход Shift Left Security, который предполагает интеграцию практик по безопасности на всех этапах разработки веб-приложений, позволяет значительно снизить риски успешных кибератак, а также минимизировать возможный ущерб даже если такие атаки произойдут.