Как проходит анализ защищенности
веб-приложений

В современной цифровой экосистеме cпециально разработанные веб-приложения (сайты, веб-ресурсы, веб-службы) стали более сложными и являются неотъемлемой частью бизнес-операций любой организации, что создает разнообразные риски информационной безопасности и представляют собой привлекательную цель для киберпреступников.

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

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

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

Наш подход и инструменты по анализу защищенности веб-приложений.
Наша командапостоянно расширяет свои навыки и имеет некоторые из самых известных сертификатов по безопасности приложений, такие как Offensive Security Web Expert (OSWE) и Burp Suite Certified Practitioner . Кроме того, мы остаемся в курсе последних угроз веб-приложений, отслеживая новые атаки по мере публикации исследований, включая те, которые представляют на хакерских конференциях.

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

Автоматизированный и ручной анализ защищенности в основном выполняется с помощью инструмента Burp Suite. Мы установили как общедоступные расширения Burp, так и некоторые из них, разработанные нами внутри компании, которые позволяют:

• Включить дополнительные автоматизированные проверки, недоступные по умолчанию; и
• Провести ручное тестирование с помощью специализированных функций.
  В основе нашего тестирования мы также используем новейшие флагманские проекты Open Web Application Security Project® (OWASP), такие как Web Security Testing Guide (WSTG), поскольку они обеспечивают покрытие большинства типов проблем безопасности, которые должны быть проверены во время проведения анализа защищенности веб-приложения.

Наш процесс проведения анализа защищенности веб-приложения.

1. Предварительный анализ

Перед проведением активного тестирования мы проведем так называемый предварительный анализ, который будет включать:

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

2. Активное тестирование – идентификация

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

Мы настроим Burp Suite для перехвата всех запросов, сделанных в веб-браузере, используемом анализа приложения. Перед началом автоматического сканирования каждый перехваченный запрос будет проходить ручную оценку.

Ручное тестирование: Сначала мы отправим базовый набор полезных нагрузок и проверим, как приложение реагирует на возможности эксплуатации. Ручное тестирование позволяет нам лучше понять, как запросы влияют на приложение, прежде чем выполнять автоматическое сканирование.
Автоматические проверки: после завершения ручного тестирования мы настроим автоматическое сканирование для проверки определенных областей в запросе, некоторые из которых включают значения параметров и заголовки HTTP.
При выполнении автоматического сканирования используется большая база данных часто обновляемых полезных нагрузок и списков уязвимостей, что позволяет сделать максимальный охват функционала приложения.

На этом этапе часто обнаруживаются следующие проблемы:

• Уязвимости аутентификации (атаки OAuth, SAML и JSON Web Tokens (JWT));
• SQL-инъекции;
• Небезопасные прямые ссылки на объект (IDOR);
• Возможности обхода авторизации;
• Сохраненный, отраженный и основанный на DOM межсайтовый скриптинг (XSS);
• Внедрение инъекции в шаблоны на стороне сервера (SSTI);
• Подделка запросов на стороне сервера (SSRF);
• Ошибки бизнес-логики;
• Раскрытие конфиденциальной информации.
  Во избежание ложных срабатывании результаты, выявленные с помощью автоматизированных проверок, таких как описанные выше или другие, затем проверяются вручную.

3. Активное тестирование – эксплуатация

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

Вот некоторые сценарии распространенных атак:

• Использование уязвимостей аутентификации, таких как захват учетной записи с помощью недостатков в процессах сброса пароля и использования слабых ключей подписи JWT;
• Злоупотребление отсутствием правил контроля доступа с точки зрения учетной записи с низкими привилегиями для получения доступа к административным областям приложения;
• Разработка полезных нагрузок XSS, демонстрирующих наихудший сценарий для вашего приложения, например, кража конфиденциальных данных, сеансовых cookie-файлов или выполнение атак типа CSRF от пользователя с низкими привилегиями для получения дополнительного доступа;
• Использование SSRF для получения данных из внутренних источников, таких как службы метаданных, используемые в облачных вычислительных средах, которые обычно раскрывают доступ и секретные ключи;
• Демонстрация того, как открытые перенаправления могут использоваться для перенаправления пользователей на вредоносные сторонние сайты, предназначенные для захвата их учетных данных;
• Использование конфиденциальной информации, полученной из ошибок трассировки стека, для выполнения цепочек эксплойтов, таких как выявление и последующее выполнение эксплоитов против утекших устаревших версий программного обеспечения и раскрытых путей к файлам, используемых в сочетании с атаками с локальными включениями файлов.

4. Документация и отчетность

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

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

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

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

ПОДЕЛИТЬСЯ