Руслан Рахметов, Security Vision
Современный ландшафт киберугроз достаточно разнороден, а в СМИ постоянно поваляются новости об утечках данных, DDoS-атаках, вирусных заражениях, кибервымогательстве и кибершпионаже. При этом есть категория кибератак, которая пользуется стабильной популярностью у злоумышленников на протяжении последних нескольких десятков лет, фактически со времени развития сети Интернет - это атаки на веб-сайты, интернет-приложения и разнообразные веб-системы. Привлекательность таких целей для атакующих легко понять: для атаки на веб-системы атакующим достаточно лишь атаковать ресурс, который публично доступен из сети интернет.
В силу указанных причин веб-ресурсы подвержены повышенному риску несанкционированного доступа, кибервзломов, эксплуатации веб-уязвимостей, что в свою очередь может привести к утечке данных (например, базы данных пользователей сайта), несанкционированному изменению внешнего вида веб-ресурса (дефейсу), размещению вредоносного или мошеннического контента на сайте без ведома владельца, а также к компрометации информационных ресурсов, к которым имеет доступ веб-сервер через корпоративную сеть. Вопросами безопасности веб-приложений уделяется много внимания в мире ИБ, например, со стороны сообщества OWASP (Open Web Application Security Project, открытый проект безопасности веб-приложений), которое в том числе формирует справочник разнообразных веб-атак. В рамках работы данного проекта с 2003 года регулярно выпускаются списки из 10 наиболее распространенных типов веб-уязвимостей и ошибок конфигурирования веб-приложений. Последняя версия данного списка OWASP Top 10 вышла в 2021 году и содержит следующие типы уязвимостей:
• Сбой механизмов контроля доступа (англ. Broken Access Control);
• Ошибки в криптографии (англ. Cryptographic Failures);
• Инъекции (англ. Injection), включая XSS, SQL-инъекции, внедрение команд ОС, внедрение выражений XPath и XQuery и т.д.;
• Небезопасный дизайн (англ. Insecure Design);
• Недостатки конфигурации (англ. Security Misconfiguration);
• Уязвимые и устаревшие компоненты (англ. Vulnerable and Outdated Components);
• Ошибки в обеспечении идентификации и аутентификации (англ. Identification and Authentication Failures);
• Ошибки в обеспечении целостности ПО и данных (англ. Software and Data Integrity Failures);
• Ошибки в обеспечении логирования и мониторинга безопасности (англ. Security Logging and Monitoring Failures);
• Подделка запросов на стороне сервера (англ. Server-Side Request Forgery).
Рассмотрим подробнее данные уязвимости.
1. Сбой механизмов контроля доступа (A01:2021-Broken Access Control)
Механизмы контроля доступа обеспечивают соблюдение политик доступа и полномочий пользователей систем для предотвращения несанкционированного доступа субъектов к объектам защиты. Распространенные уязвимости контроля доступа включают в себя несоблюдение принципов наименьших полномочий и запрета по умолчанию, обход проверок доступа путем изменения HTML и API запросов, доступ к объектам по прямой ссылке без аутентификации, отсутствие контроля доступа при выполнении POST, PUT и DELETE запросов при доступе через API, несанкционированное повышение привилегий (включая обход механизма аутентификации), манипуляция метаданными (включая повторное использование или подделка JWT-токенов, cookie-файлов, скрытых полей), ошибки конфигурирования механизма CORS (Cross-Origin Resource Sharing, совместное использование ресурсов разными источниками).
2. Ошибки в криптографии (A02:2021-Cryptographic Failures)
Недостатки в применении криптографических методов защиты информации при хранении, использовании и передаче могут привести к несанкционированному доступу, разглашению и утечке данных. Особое внимание требуется уделить криптографической защите данных, безопасность которых регулируется законодательными нормами, например, персональных данных, банковской информации, коммерческой тайны, а также чувствительных данных, таких как аутентификационная информация (логины, пароли, email, телефон). Для подобных конфиденциальных данных следует определить, не передаются ли они в незашифрованном виде (clear text), не используются ли нестойкие, ненадежные, устаревшие криптографические функции и их режимы, внедрено ли управление криптографическими ключами, присутствуют ли требования по принудительному применению стойкой криптографии для веб-клиентов, проверяются ли цепочки доверия криптографических сертификатов, не используются ли пароли в качестве криптографических ключей без применения PBKDF-функции, какие генераторы случайных чисел используются, не применяются ли устаревшие функции хэширования (MD5, SHA1).
3. Инъекции (A03:2021-Injection)
Веб-приложение является уязвимым для атак методом инъекции в случае, когда передаваемые пользователем данные не проверяются, не фильтруются, не санитизируются веб-приложением, используются динамические запросы и непараметризованные вызовы функций без экранирования пользовательского ввода, небезопасный пользовательский ввод передается в запросы, команды, хранимые процедуры. Наиболее распространенными типами инъекций являются SQL/NoSQL-инъекции, внедрение команд ОС, ORM-инъекции (Object Relational Mapping), инъекции LDAP, EL (Expression Language), OGNL (Object Graph Navigation Library). Вне зависимости от используемого веб-приложением интерпретатора (JavaScript, PHP, Python и т.д.), лучшим способом предотвращения подобных уязвимостей будет проверка исходного кода, которую следует выполнять для всех параметров, заголовков, URL, cookie-файлов, данных JSON, SOAP, XML. Для автоматизации подобных проверок можно использовать средства статического анализа кода (SAST, Static Application Security Testing), динамического анализа кода (DAST, Dynamic Application Security Testing), интерактивного анализа кода (IAST, Interactive Application Security Testing), которые можно интегрировать в CI/CD-конвейер.
4. Небезопасный дизайн (A04:2021-Insecure Design)
Небезопасный дизайн - это широкое определение для ошибок и уязвимостей, допущенных в результате отсутствующей или неэффективной разработки мер контроля при проектировании веб-приложения. Следует различать небезопасный дизайн веб-приложения и его небезопасную реализацию: даже при безопасном дизайне некорректная реализация может привести к возникновению уязвимостей, а небезопасный дизайн не может быть исправлен качественной реализацией, поскольку необходимые функции безопасности не были заложены на этапе проектирования системы. Одной из причиной небезопасного дизайна является недостаток оценки бизнес-рисков, моделирования киберугроз и правил безопасного проектирования систем, что приводит к невозможности определения уровня безопасности веб-системы на этапе проектирования.
Для разработки безопасного дизайна веб-приложений следует собирать и согласовывать бизнес-требования к приложению с заинтересованными лицами, включая требования к защитному функционалу для обеспечения конфиденциальности, целостности, доступности, подлинности используемых системой данных и её логики работы. Следует учитывать степень потенциальной доступности веб-приложения для атак, а также необходимость в сегрегации данных между тенантами. Следует сформулировать и агрегировать все технические требования, включая требования по безопасности, а затем запланировать расходы на проектирование, разработку, тестирование и эксплуатацию веб-приложения с учетом обеспечения кибербезопасности. Безопасное проектирование также должно включать в себя непрерывную оценку киберугроз, проектирование и разработку веб-приложений для предотвращения реализации различных методов кибератак.
Моделирование угроз должно быть интегрировано в рефайнмент-сессии, на которых следует обращать внимание на изменения в потоках данных, контролях доступа, мерах защиты. При разработке user story следует сформулировать корректный рабочий процесс веб-приложения и определить способы обработки ошибок, согласовать их с ответственными и заинтересованными лицами. Кроме того, следует проводить анализ допущенных ошибок и предлагать инициативы для улучшения продукта.
Безопасная разработка требует внедрения жизненного цикла разработки ПО, наличия шаблонов безопасного проектирования, методологии, библиотеки безопасных программных компонентов, инструментов безопасной разработки, средств моделирования угроз. Для повышения безопасности приложений следует использовать концепцию «сдвига влево», которая позволяет учитывать киберриски, начиная с самых первых этапах разработки веб-систем.
5. Недостатки конфигурации (A05:2021-Security Misconfiguration)
Веб-приложение окажется уязвимым в случаях, когда отсутствуют меры защиты в стеке используемых приложением технологий, некорректно настроены разрешения в облачных сервисах, установлен или активирован избыточный функционал (например, лишние сетевые порты, сервисы, страницы, учетные записи, привилегии), включены и оставлены без изменений учетные записи и пароли по умолчанию, сообщения об ошибках содержат избыточную техническую информацию, отключается или не настраивается обновленный защитный функционал при обновлении веб-системы, настройки на серверах приложений, в фреймворках, библиотеках и базах данных не соответствуют рекомендуемым безопасным значениям, веб-сервер не передает заголовки безопасности и директивы, либо они не соответствуют безопасным значениям. Подчеркивается, что без согласованного, повторяемого процесса безопасной настройки приложений веб-системы подвергаются повышенному риску.
6. Уязвимые и устаревшие компоненты (A06:2021-Vulnerable and Outdated Components)
Данной уязвимости будут подвержены веб-приложения, для которых неизвестны версии всех используемых компонент (и клиентских, и серверных), включая непосредственно используемые компоненты и программные зависимости. Опасно также использовать уязвимое, неподдерживаемое, устаревшее ПО, включая ОС, веб-серверы и серверы приложений, СУБД, приложения, API, среды выполнения, программные библиотеки. Важно регулярно проводить сканирование на наличие уязвимостей и получать информационные бюллетени по уязвимостям для используемых компонент, оперативно обновлять используемые платформы, фреймворки, зависимости с использованием риск-ориентированного подхода. Кроме того, разработчикам важно проводить тестирование обновляемых библиотек на совместимость, а также обеспечивать защищенную настройку компонент приложений.
7. Ошибки в обеспечении идентификации и аутентификации (A07:2021-Identification and Authentication Failures)
Подтверждение личности пользователя, аутентификация, управление сессиями критически важно для противодействия атакам на процессы аутентификации. Уязвимости в обеспечении идентификации и аутентификации могут возникнуть в случае, когда приложение подвержено атакам типа credential stuffing (подстановка учетных данных из баз «утекших» логинов и паролей), не защищено от брутфорса или других автоматизированных атак, допускает использование дефолтных, слабых или хорошо известных паролей, использует слабый или неэффективный процесс восстановления паролей, допускает использование паролей в чистом виде или применяет слабые алгоритмы шифрования и хэширования паролей, не задействует или применяет неэффективные средства мультифакторной аутентификации, отображает идентификатор сессии в URL, допускает повторное использование сессионного идентификатора, не аннулирует корректным образом сессионные идентификаторы или токены аутентификации после выхода пользователя или по истечению периода неактивности.
8. Ошибки в обеспечении целостности ПО и данных (A08:2021-Software and Data Integrity Failures)
Ошибки в целостности программ и данных обусловлены исходным кодом и инфраструктурой, которые не защищают от нарушений целостности. Примером может быть приложение, в котором используются плагины, библиотеки, модули из недоверенных источников и репозиториев. Использование небезопасного CI/CD-конвейера может стать источником несанкционированного доступа, внедрения вредоносного кода, компрометации системы. Кроме того, приложения могут использовать функционал установки автоматических обновлений, которые скачиваются и устанавливаются без необходимой проверки целостности, а атакующие потенциально могут загружать модифицированные обновления, которые затем будут распространены и запущены на всех инсталляциях приложения. Еще один пример ошибки в обеспечении целостности - небезопасная десериализация данных, при которой сериализованные или закодированные данные незащищены от модификации злоумышленником.
9. Ошибки в обеспечении логирования и мониторинга безопасности (A09:2021-Security Logging and Monitoring Failures)
Для выявления и реагирования на кибератаки важно использовать механизмы логирования и мониторинга событий безопасности. Без данных механизмов незамеченными могут пройти такие опасные явления, как попытки входа и высокорискованные операции, неполные или вовсе отсутствующие предупреждения и оповещения об ошибках, опасная активность приложений и API. Опасной практикой является исключительно локальное хранение логов (например, без системы централизованного сбора), а также отсутствие или неэффективность процессов реагирования на предупреждения и алерты. Признаком наличия допущенных ошибок в обеспечении логирования является отсутствие оповещений при проведении пен-тестов и сканирований средствами динамического анализа кода, а также неспособность приложения выявлять и предупреждать об активных кибератаках в режиме реального времени. Кроме того, не следует забывать, что если логи или предупреждения доступны для просмотра любым посторонним или потенциальным атакующим, то присутствует уязвимость вида «Сбой механизмов контроля доступа», описанная в самом начале.
10. Подделка запросов на стороне сервера (A10:2021-Server-Side Request Forgery)
Уязвимость типа подделки запросов на стороне сервера (SSRF, Server-Side Request Forgery) может возникнуть в случае, когда веб-приложение получает данные удаленного ресурса без проверки передаваемого пользователем URL. Такое поведение дает атакующим возможность заставить приложение отправить сформированный ими запрос по непредусмотренному адресу, минуя защитные решения, а затем вернуть ответ атакующим. Результатом успешной SSRF-атаки может стать обход установленных сетевых ограничений и прав доступа, извлечение конфиденциальной информации и чтение локальных файлов на веб-сервере, сканирование и получение доступа к внутренней сети. Опасность SSRF-атак в том, что современные веб-приложения зачастую предоставляют пользователям возможность загрузки данных со сторонних ресурсов, а сложность современных инфраструктур и повсеместное использование «облаков» приводит к повышению вероятности обнаружения и эксплуатации SSRF-уязвимости.
