В блог
Статьи
04/06/2026
Пентест веб-приложений: полный цикл от разведки до отчета
Наталья Лабынцева
Ведущий консультант по ИБ в «КИТ»
Веб-приложения — самые распространенные внешние ресурсы, доступные из сети Интернет, поскольку они позволяют компаниям взаимодействовать с клиентами и партнерами, предоставлять услуги и просто информировать о деятельности не только коммерческих организаций, но и государственных и муниципальных органов. Такие приложения окружают нас повсюду в повседневной жизни: личные кабинеты, сервисы бронирования билетов и гостиниц, даже социальные сети. Соответственно, обеспечивать кибербезопасность веб-сайтов является важной задачей, которая стоит перед бизнесом и внутренними специалистами. Причем стоит отметить, что обеспечивать безопасность веб-ресурсов должны не только специалисты по информационной безопасности (далее — ИБ), но и сотрудники отдела информационных технологий (далее — ИТ): DevOps, разработчики, системные администраторы и другие, кто задействован в функционировании приложения.
Важность ИБ на уровне ИТ-специалистов обусловлена тем, что они участвуют в разработке веб-приложения и его последующем администрировании, а именно в улучшении, устранении уязвимостей или иных ошибок. Так, обеспечение ИБ веб-ресурсов заключается, в том числе, в применении правил безопасной разработки, безопасности исходного кода и тестировании на отсутствие ошибок логики, реализация которых может привести к негативным последствиям. Например, ошибки бизнес-логики могут привести к потере денежных средств, когда из-за некорректной функциональности баланс пользователя округляется в большую сторону (0,9 рубль округляется до 1 рубля и при многократном повторении округления происходят утечки больших сумм). А отсутствие процессов безопасной разработки может привести к наличию уязвимостей в исходном коде, приводящих к получению административных прав, или к наличию комментариев разработчиков между строк кода, позволяющих нарушителю узнать важную информацию об архитектуре приложения. Файрвол веб-приложений (Web Application Firewall — WAF) не поможет в полной мере закрыться от таких уязвимостей и ошибок. Выявить их и показать возможность их использования для реализации негативных (недопустимых) событий поможет проверка безопасности в виде тестирования на проникновение (пентест).
Нелегитимное проникновение в веб-приложение открывает для злоумышленника различные вектора для деструктивных действий: кража персональных данных, получение привилегированных прав с подменой информации на странице (так называемый Deface), утечка коммерческой тайны, вывод денежных средств. Взлом веб-ресурсов влечет за собой не только финансовые, но и репутационные риски, когда осуществляется подрыв доверия клиентов и партнеров к компании, а также могут быть негативные публикации в средствах массовой информации.
При этом не стоит забывать, что веб-приложения могут размещаться как на ресурсах хостинг-провайдера, так и на специально выделенных мощностях компании (в идеале – в демилитаризованной зоне). Так, приложения могут открывать точки входа в локальную сеть организации, позволяя злоумышленнику осуществлять деструктивные действия не только на внешнем периметре, но и внутреннем.
Таким образом, можно сказать, что пентест веб-приложений проводится для того, чтобы:
  • получить общую оценку по анализу защищенности (выявление уязвимостей, недостатков, ошибок);
  • выявить вектора проникновения во внутреннюю сеть компании;
  • оценить возможность реализации недопустимых событий (кража или удаление данных, подмена информации, компрометация инфраструктуры ресурса).
В данной статье мы рассмотрим основные этапы проведения работ по тестированию веб-приложений.
1. Разведка
Работы по анализу защищенности всегда начинаются с разведки — с изучения тестируемых ресурсов.
Перед началом работ владелец (заказчик) предоставляет перечень веб-приложений, защищенность которых требуется оценить. В данной статье мы не говорим о тестировании внешнего периметра, в рамках которого может встречаться множество веб-приложений, а рассматриваем отдельно взятое веб-приложение, которое захотел проверить заказчик. Доступ к тестируемому веб-приложению может быть предоставлен как в тестовой среде (так называемый dev-стенд, специально выданный к тестированию), так и в «боевой» среде (так называемая prod-среда — легитимное веб-приложение, которое функционирует в реальном времени и им параллельно пользуются иные пользователи).
Отдельно следует отметить изучение ролевой модели тестируемого приложения. На практике зачастую для этой подзадачи исследователю выдают тестовую (-ые) учетную запись (далее — УЗ) в зависимости от имеющихся ролей в конкретном веб-приложении. Здесь важно понимать отличие тестирования внешнего периметра, которое обычно проходит без УЗ (формат «black box», в котором без ограничения общности цель — проникновение во внутреннюю инфраструктуру), от тестирования отдельно взятого веб-приложения с объемной функциональностью и архитектурой, решающего прикладную бизнес-задачу. Чтобы изучить комплексно и емко тестируемый продукт, над которым трудилась целая команда разработчиков, необходимо смотреть на него с разных сторон (разных ролей пользователей), а не ограничиваться только лишь формой авторизации или доступными директориями без осуществления аутентификации. Это обусловлено тем, что вероятность в 2026 году найти уязвимость, например, позволяющую с помощью SQL-инъекции попасть в авторизованную или даже административную зону веб-ресурса через панель авторизации, мала (но никогда не равна нулю), то есть, из-за объемной функциональности и улучшающихся механизмов защиты в современных веб-приложениях редко встречаются такие банальные уязвимости, но в то же время остаются популярными ошибки контроля доступа (англ. Broken Access Control по OWASP Top 10 2025 г.) и для выявления данного класса уязвимостей зачастую нужна УЗ. Однако, существуют ситуации, когда тестовая УЗ не предоставляется, а регистрируется специалистом самостоятельно, если для этого действия с точки зрения бизнес-процессов не нужны дополнительные верификации третьей стороной (например, поход в банк, офис или регистрация на основе паспортных данных исследователя). Данные условия тестирования и формат работ обсуждаются перед активной фазой анализа защищенности веб-приложения.
Так или иначе получив перечень тестируемых веб-ресурсов и согласовав получение УЗ (выдана тестовая или зарегистрирована самостоятельно), специалисты по анализу защищенности переходят к их изучению. Так, при разведке осуществляется сбор следующих данных о приложениях:
  • используемые языки программирования (PHP, Java, Python и т. д.);
  • собираемые cookie-файлы;
  • применяемые службы и плагины, например, если приложение разработано на базе системы управления содержимым сайта (Content Management System — CMS, примеры: Bitrix, Joomla, Wordpress) или использует на клиентской части jQuery — популярную библиотеку языка JavaScript;
  • функциональность приложения, способы загрузки данных (формы обратной связи, авторизация пользователей и т. д.);
  • перечень директорий и конечных точек (посредством автоматического обхода, так называемый краулинг, веб-ресурса, например, с помощью инструмента katana или напрямую перебором директорий по словарю).
При этом важно изучить не только используемые технологии, но и логику работы приложения и способы взаимодействия с пользователями. Так, в открытых источниках можно найти полезную информацию, позволяющую пользователю воспользоваться легитимной функциональностью, а для пентестера такая информация будет открывать один из путей проникновения или реализации деструктивных действий. Например, если в открытом доступе находятся сведения о парольной политике, то специалист по анализу защищенности может ею воспользоваться для перебора пароля и попытки входа от лица какого-либо пользователя.
От грамотного подхода на данном этапе зависит понимание архитектуры тестируемого веб-приложения и более качественный поиск потенциальных слабых мест.
2. Эксплуатация уязвимостей
После этапа разведки специалисты приступают к непосредственным попыткам эксплуатации уязвимостей. При данных работах пентестеры тестируют приложение путем вызова ошибок, попыток обхода способов защиты, раскручивания недостатков ресурса. Например, под обходом защиты понимается не только обход используемых средств защиты информации (по типу WAF), но и встроенных функций защиты в виде недопустимости загрузки файлов, формат которых не соответствует разрешенным. В таком примере специалист по анализу защищенности будет пытаться загрузить файл с неразрешенным форматом, чтобы разместить его на серверной составляющей приложения для дальнейшего продвижения и захвата.
Также, обладая знаниями об используемых технологиях, пентестеры могут эксплуатировать общеизвестные уязвимости соответствующих программ (технологий). Например, зная версию системы управления содержимым сайта (CMS), специалист может попытаться использовать ранее выявленную и известную уязвимость из база данных CVE (Common Vulnerabilities and Exposures). Общеизвестные уязвимости из CVE изучаются в сообществе пентестеров, которые в свою очередь разрабатывают эксплойты — последовательность команд, позволяющие эксплуатировать уязвимость в программном обеспечении. Соответственно, в рамках тестирования веб-приложения наличие устаревших версий технологий открывает дополнительные вектора атак и является слабым звеном в защите.
Основной задачей данного этапа является ручное подтверждение обнаруженных недостатков для будущей фиксации в отчете.
3. Анализ исходного кода
Дополнительно для комплексного анализа защищенности веб-приложений владелец (заказчик) может предоставить исходный код, чтобы выявить уязвимости, которые не видно на первый взгляд и которые можно не заметить в условиях временных ограничений при классическом тестировании. Такой подход нередко называется «белым ящиком» (англ. White box), так как у исследователя есть полные сведения о тестируемом приложении. Процесс анализа исходного кода позволяет комплексно реализовать тестирование и при выстроенных процессах безопасной разработки отловить уязвимости на первых этапах разработки новой функциональности. Кроме того, в рамках данного подхода можно выявить общеизвестные уязвимости (CVE) в сторонних плагинах, библиотеках и фрейморках, используемых в коде, и обновить их до актуальных версий. Здесь стоит отметить, что исправление уязвимости в готовом приложении обходится в разы дороже, чем предотвращение ошибки на стадии проектирования или написания кода, поэтому данный вид анализа веб-приложений также важен.
4. Реализация недопустимых событий
Нередко заказчик просит показать демонстрацию так называемых недопустимых событий — подмножество событий, реализация которых делает невозможным достижение операционных или стратегических целей компании либо критически нарушает ее основную деятельность. Для веб-приложений типовыми недопустимыми событиями являются:
  • Утечка данных: кража персональной информации клиентов, баз данных интеллектуальной собственности или конфиденциальных документов через некорректные права доступа в веб-приложении к чужим данным. Реализация такого события влечет за собой финансовые и репутационные потери для компании (подрыв доверия, штрафы, компенсации);
  • Финансовые потери: хищение крупных сумм со счетов компании в случае, если уязвимость обнаружена в функциональности оплаты товаров или услуги.
  • Репутационный ущерб: например, потеря ключевых VIP-клиентов или подрыв их доверия в результате массового захвата аккаунтов таких пользователей веб-приложения.
Перед предоставлением перечня событий заказчик обычно оценивает, какие именно события критичны для его сферы деятельности. Далее он их может адаптировать под более прикладные технические задачи в контексте веб-приложения, например:
  • реализовать доступ к панели администратора портала;
  • получить доступ к отчету чужого пользователя;
  • получение доступа к платному контенту без факта оплаты;
  • множество иных задач, зависящих от бизнес-логики тестируемого веб-приложения.
5. Формирование отчета
После завершения активных работ любому заказчику важно увидеть итоговый результат — для этого необходимо составить качественный, хорошо структурированный и понятный отчет. Многие специалисты по тестированию на проникновение не любят данную рутину, но этот этап работ является важным, ведь конечным итогом любых тестирований является отчетная документация, с которой в дальнейшем работает заказчик (устраняет уязвимости, повышает защищенность ИТ-инфраструктуры, пересматривает функциональности и процессы).
Хороший отчет по анализу защищенности веб-приложения должен содержать в первую очередь грамотный и понятный PoC (англ. Proof of Concept) — подтверждение конкретной уязвимости в виде детального пошагового описания необходимых действий для ее реализации с соответствующими доказательствами. Такими свидетельствами эксплуатации уязвимости могут быть приложенные HTTP-запросы, скриншоты в высоком разрешении с указанием и подчеркиванием областей экрана. Данные действия нужны для того, чтобы ИТ- или ИБ-специалисты заказчика без труда воспроизвели обнаруженный недостаток. В частности, в случае сложной цепочки эксплуатации, можно дополнительно предоставить видео или GIF-изображение с наглядной демонстрацией шагов.
Также в отчете должна содержаться информация о фактуре работ: исследуемые модели нарушителя в конкретном веб-приложении, используемое программное обеспечение, методика работ, технические ограничения (например, если исследователя добавили в исключения на WAF). Дополнительно следует уделить внимание информации для руководства, где необходимо написать простым и понятным языком достигнутые результаты и потенциальные последствия от эксплуатации недостатков без технических деталей. Для грамотного донесения информации до топ-менеджмента как раз будут полезны упомянутые выше недопустимые события, если их удалось достичь. Так, будет показана польза от проведенных работ и критичность выявленных слабых мест на языке бизнеса.
Таким образом, подводя итог всему вышесказанному, пентест веб-приложений позволяет оценить общий уровень безопасности конкретного ресурса, с которым чаще всего взаимодействуют клиенты, партнеры и контрагенты компании и слабая защищенность которого может привести к негативным последствиям для бизнеса.