Пентест сайта и веб-приложений
Проверим, можно ли взломать ваш сайт, личный кабинет или интернет-сервис и что через это можно сделать: украсть данные, войти в чужой аккаунт, обойти ограничения, загрузить вредоносный файл, получить доступ к внутренним системам.
По итогам пентеста вы получаете отчет с подтвержденными сценариями атак, оценкой риска и рекомендациями по исправлению.
Кибератаки через веб-приложения и сайты реальны
| 70% успешных атак | До 1 года | 85% веб-приложений | До 21 млн руб. |
|---|---|---|---|
| используют веб-приложения и API в качестве вектора | может существовать закладка (бэкдор) злоумышленника в действующем веб-приложении | содержат уязвимость из перечня OWASP Top 10 | может составлять стоимость одного часа простоя, вызванного кибератакой или шифрованием данных |
Тестирование на проникновение для профилактики кибератак и поиска уязвимых мест в инфраструктуре
Веб-приложения и сайты являются основными точками входа для злоумышленников — через них происходит большинство целевых атак на компании. Мы проводим контролируемое тестирование защищённости ваших веб-ресурсов, чтобы выявить уязвимости до того, как их обнаружат злоумышленники, и не допустить компрометации данных, перехвата управления или нарушения доступности сервисов.
Наши специалисты моделируют действия реальных внешних и внутренних нарушителей и пытаются проникнуть в инфраструктуру через веб-приложения. В ходе работ применяются автоматизированные инструменты и ручной анализ.
Цель тестирования — не просто найти уязвимости, а подтвердить возможность их эксплуатации, оценить потенциальные последствия для бизнеса и подготовить план устранения.
Варианты проведения пентеста сайта
| Black Box тестирование «вслепую» | Gray Box комбинированное тестирование | White Box тестирование с полным доступом |
|---|---|---|
| Тестирование проводится с позиции внешнего злоумышленника, который может взаимодействовать только с общедоступными интерфейсами: сайтом, API и формами ввода. Специалисты не получают доступ к исходному коду, документации и сведениям об архитектуре приложения. Подход позволяет оценить защищённость веб-ресурса в условиях, максимально приближенных к реальной внешней атаке. | Команде предоставляется ограниченный объём информации: например, учётные записи пользователей с разными ролями, описание API, отдельные фрагменты кода или схемы баз данных. Это позволяет сосредоточиться на механизмах авторизации, управлении сессиями и бизнес-логике, а также сократить область поиска. | Специалистам предоставляется полный доступ к исходному коду, архитектуре, конфигурации серверов и документации. Подход позволяет провести статический анализ кода, выявить логические ошибки, скрытые бэкдоры, недостатки реализации криптографических механизмов и некорректные настройки безопасности. Рекомендуется для критически важных систем и приложений, обрабатывающих персональные или платёжные данные. |
Что мы проверяем
- Внешний периметр — общедоступные сайты, порталы, личные кабинеты и интернет-магазины.
- Внутренние веб-системы — корпоративные порталы, CRM, ERP и системы управления документами.
- API — программные интерфейсы REST, GraphQL и SOAP, через которые взаимодействуют frontend, backend и сторонние сервисы.
- Инфраструктурные компоненты — веб-серверы, балансировщики, кеширующие прокси и базы данных.
- Бизнес-логика — процессы регистрации, авторизации, оплаты, оформления заказов и передачи прав.
Методология и подход
- Упор на ручной анализ, а не только на результаты сканирования. Автоматизированные средства, включая OWASP ZAP и Burp Suite, используются как один из этапов и помогают сформировать карту возможных проблем. Основная часть работ приходится на ручной поиск логических уязвимостей, цепочек атак и нестандартных векторов.
- Многовекторный анализ. Веб-приложение исследуется на уровне клиентской части, сетевого взаимодействия, API, серверной логики и инфраструктуры. При необходимости в область работ включаются сценарии, связанные с человеческим фактором.
- Подтверждение найденных уязвимостей. Специалисты проверяют возможность практической эксплуатации каждого существенного недостатка в согласованных границах тестирования.
- Оценка последствий для бизнеса. Уязвимости приоритизируются с учётом возможной утечки данных, финансового ущерба, нарушения доступности сервисов и получения доступа к внутренним системам.
- Практические отчёты. Заказчик получает доказательную базу, инструкции по воспроизведению и рекомендации по устранению, а не автоматический перечень результатов сканирования.
При проведении работ учитываются положения следующих стандартов и методических документов:
- OWASP Web Security Testing Guide — руководство по тестированию безопасности веб-приложений;
- NIST SP 800-115 — руководство по техническому тестированию и оценке информационной безопасности;
- PTES — стандарт выполнения тестирования на проникновение;
- OSSTMM — методология оценки операционной безопасности;
- ГОСТ Р 58143-2018 «Информационная технология. Методы и средства обеспечения безопасности. Детализация анализа уязвимостей программного обеспечения в соответствии с ГОСТ Р ИСО/МЭК 15408 и ГОСТ Р ИСО/МЭК 18045. Часть 2. Тестирование проникновения»;
- ГОСТ Р ИСО/МЭК 18045-2013 — методология оценки безопасности информационных технологий.
Какие векторы атак проверяются
1. Инъекции
Проверяется возможность внедрения SQL-, NoSQL-, LDAP- и системных команд через поля ввода, параметры URL, HTTP-заголовки и другие данные, обрабатываемые приложением.
2. Ошибки аутентификации и управления сессиями
Тестируются механизмы входа и восстановления пароля, функция «Запомнить меня», обработка JWT-токенов, завершение сессий и устойчивость к атакам Session Fixation и Session Hijacking.
3. Межсайтовый скриптинг
Проверяется возможность проведения отражённых, хранимых и DOM-based XSS-атак с выполнением внедрённого JavaScript-кода в браузере пользователя.
4. Межсайтовая подделка запроса
Анализируется, может ли злоумышленник заставить авторизованного пользователя выполнить нежелательное действие без его ведома.
5. Подбор учётных данных
Проверяется устойчивость приложения к перебору паролей, распылению паролей и другим автоматизированным атакам на учётные записи.
6. Небезопасная десериализация
Исследуется обработка сериализованных данных и возможность удалённого выполнения кода или других несанкционированных действий.
7. Server-Side Request Forgery
Проверяется возможность заставить сервер отправлять запросы во внутреннюю сеть, облачную инфраструктуру или к сторонним системам.
8. XML External Entity
Анализируются XML-парсеры и возможность доступа к локальным файлам, внутренним ресурсам или нарушения доступности сервиса.
9. Раскрытие чувствительных данных
Проверяется наличие персональных данных, паролей и ключей в ответах сервера, исходном коде, комментариях, журналах и открытых Git-репозиториях.
10. Некорректная конфигурация безопасности
Анализируются HTTP-заголовки CSP, HSTS и X-Frame-Options, открытые порты, стандартные учётные записи, доступные административные панели и другие настройки.
11. Ошибки авторизации
Проверяется возможность доступа к чужим записям, файлам и другим объектам без надлежащего контроля прав, включая уязвимости класса IDOR.
12. Уязвимости бизнес-логики
Выявляются ошибки, позволяющие обходить лимиты, изменять цены, получать несанкционированные скидки или выполнять операции с нарушением установленного порядка.
13. Атаки на API
REST-, GraphQL- и SOAP-интерфейсы проверяются на Mass Assignment, инъекции через параметры, недостаточное ограничение частоты запросов и перебор идентификаторов.
14. Проблемы с кешированием и CDN
Проверяется возможность сохранения и получения чувствительных данных через кеширующие серверы и сети доставки контента.
15. Уязвимости сторонних компонентов
Используемые библиотеки и фреймворки анализируются на наличие известных уязвимостей.
Нормативная основа проведения работ
- Методический документ ФСТЭК России «Методика анализа защищённости информационных систем» от 25 ноября 2025 года. Определяет организацию, порядок и содержание анализа защищённости, включая тестирование веб-приложений, входящих в состав информационных систем.
- Приказ ФСТЭК России от 11 апреля 2025 года № 117. Устанавливает требования к защите информации в государственных информационных системах и иных информационных системах государственных органов.
- Приказы ФСТЭК России № 17, № 21 и № 31. Содержат требования к выявлению и устранению уязвимостей программного обеспечения для соответствующих категорий информационных систем.
- Методические рекомендации Банка России по проведению тестирования на проникновение. В область тестирования могут включаться системы дистанционного банковского обслуживания, личные кабинеты, веб-интерфейсы для юридических лиц и API, обеспечивающие взаимодействие с другими системами.
- Рекомендации в области стандартизации Банка России РС БР ИББС-2.6-2014. Содержат положения об оценке защищённости веб-приложений, используемых организациями финансового сектора.
- ГОСТ Р 58143-2018. Определяет процесс тестирования проникновения на основе требований к анализу уязвимостей программного обеспечения.
- Федеральный закон от 27 июля 2006 года № 152-ФЗ «О персональных данных». Устанавливает обязанность операторов принимать меры по обеспечению безопасности персональных данных и проводить оценку эффективности реализованных мер.
- Требования к защите ГИС, АСУ ТП и объектов КИИ. Учитываются при тестировании веб-интерфейсов, входящих в состав соответствующих информационных систем.
Этапы пентеста сайта
| Этап | Что выполняют специалисты | Результат этапа |
|---|---|---|
| 1. | Планирование и согласование Определение границ тестирования: URL, подсетей и API. Согласование целей, правил проведения работ, точек контакта и исключаемых систем. Выбор модели Black Box, Gray Box или White Box. | Согласованный план, границы и правила проведения тестирования. |
| 2. | Сбор информации Пассивный и активный сбор данных о доменах, поддоменах, IP-адресах, открытых портах, версиях веб-серверов, используемых фреймворках, структуре приложения и доступных файлах. | Профиль поверхности атаки, включая карту URL, параметров и конечных точек API. |
| 3. | Сканирование и анализ уязвимостей Применение автоматизированных средств для выявления известных недостатков и ручной анализ для поиска логических, архитектурных и комбинированных уязвимостей. | Предварительный перечень выявленных уязвимостей с классификацией. |
| 4. | Эксплуатация уязвимостей Проверка возможности практической эксплуатации выявленных недостатков: получения доступа к базам данных, файловой системе, внутренним сервисам, пользовательским сессиям или выполнению команд. | Доказательства реализуемости выявленных сценариев атак. |
| 5. | Постэксплуатационный анализ Определение доступных после компрометации систем и данных, возможности дальнейшего перемещения по инфраструктуре и развития атаки. | Оценка технических последствий и рисков для бизнеса. |
| 6. | Подготовка отчёта и презентация результатов Описание уязвимостей, уровней критичности, сценариев воспроизведения, доказательств эксплуатации и рекомендаций по устранению. Представление результатов технической и управленческой командам. | Приоритизированный план повышения защищённости веб-приложения и связанных систем. |
Почему САЙБЕР Бизнес Консалтинг
-
1
Команда
Наши консультанты сертифицированы на международном уровне и имеют сертификаты CISA, CISM и CISSP, что подтверждает их опыт, квалификацию и знания в области информационной безопасности, управления рисками и проектами.
-
2
Долгосрочное сотрудничество
Наша цель — построить долгосрочные взаимовыгодные отношения с клиентом, поэтому, выполняя даже минорную работу, мы всегда фокусируемся на решении его стратегических задач.
-
3
Экспертиза
Наши консультанты обладают значительным опытом в ИТ и знакомы с его особенностями, присущими различным отраслям и индустриям, а также хорошо ориентируются в тенденциях и проблемах конкретных отраслей.
Стоимость услуг по проведению пентеста сайта и веб-приложений
| Услуга | Стоимость | Срок | Действие |
|---|---|---|---|
Консультация |
Бесплатно |
Отзывы и благодарности
Отвечаем на вопросы
-
Чем пентест сайта отличается от пентеста веб-приложения?
Пентест сайта обычно связан с проверкой публичной части ресурса: страниц, форм, авторизации, личных кабинетов, административных панелей, загрузки файлов и других функций, доступных через интернет.
Пентест веб-приложения чаще глубже и шире. Он нужен там, где есть сложная логика, роли пользователей, большое количество действий внутри системы, нестандартные процессы, API, интеграции и внутренние сценарии работы. Это может быть личный кабинет клиента, B2B-платформа, внутренний портал, сервис для сотрудников или сложный интернет-сервис.
Проще говоря: пентест сайта — это чаще про внешний доступный сервис; пентест веб-приложения — это про более сложную систему с логикой, ролями, действиями и внутренними связями.
На практике эти услуги часто пересекаются, поэтому формат проверки лучше определять после изучения конкретного проекта.
-
Вы ничего не сломаете?
Нормально организованный пентест не должен превращаться в хаос. Перед началом работ всегда согласуются границы проверки: что можно тестировать, в какое время, какие действия допустимы, какие разделы критичны для бизнеса и какие сценарии нужно исключить.
Если у сайта есть чувствительные функции, высокая нагрузка, боевой личный кабинет, платежные операции или интеграции с внутренними системами, это отдельно учитывается в плане работ. Опасные действия не делаются наугад. Они либо ограничиваются, либо выносятся в отдельное окно, либо заменяются более безопасным сценарием проверки.
То есть задача пентеста — не уронить сайт, а показать, где реальные риски и как ими могут воспользоваться. Именно поэтому работы всегда проводятся в согласованных рамках.
-
Поможете составить техническое задание для пентеста?
Да. Это нормальная практика. У многих заказчиков нет готового технического задания, потому что они не обязаны разбираться в деталях проведения пентеста.
Обычно на старте достаточно базовой информации: какой сайт или сервис нужно проверить, какие разделы и функции в приоритете, есть ли личные кабинеты, административные панели, API, формы загрузки файлов, есть ли ограничения по времени и критичные бизнес-процессы, нужен ли black box, gray box или white box формат.
На основе этого можно подготовить понятное ТЗ: с границами проверки, составом работ, ограничениями, результатом и форматом отчетности.
-
Как часто нужно проводить пентест?
Единого ответа для всех нет, но есть нормальная практическая логика.
Пентест стоит проводить перед запуском нового сайта или сервиса, после серьезных доработок, после смены подрядчика или команды разработки, после подключения новых интеграций, после инцидента или попытки взлома, а также периодически, если сайт критичен для бизнеса и постоянно меняется.
Если сайт активно развивается, одна проверка когда-то давно почти ничего не гарантирует. Безопасность сайта меняется вместе с его кодом, логикой и инфраструктурой.
-
В пентесте сайта есть проверки узлов, хостинга, сервера, базы данных, регистратора и других подобных вещей?
Это зависит от границ работ.
Базовый пентест сайта обычно сосредоточен на самом сайте или веб-приложении: страницах, формах, кабинетах, API, авторизации, логике работы и связанных функциях.
Но при необходимости в проект можно включить и смежные компоненты: сервер, на котором размещен сайт, конфигурацию веб-сервера, базы данных и доступ к ним, панели управления хостингом, почтовые и служебные сервисы, DNS и настройки домена, а также отдельные узлы, которые связаны с работой сайта.
Главное — заранее определить, что именно входит в объем работ. Иначе у заказчика одно ожидание, а у исполнителя другое.
-
Пентест каких CMS вы делаете? Проверяете ли самописные сайты и сайты на каких языках программирования?
Да. Пентест можно проводить как для популярных CMS, так и для самописных решений.
Проверка возможна для сайтов на WordPress, Bitrix, Joomla, Drupal, OpenCart и других системах, а также для самописных проектов на PHP, Python, JavaScript, Node.js, Java, .NET и других языках и фреймворках.
Для нас важнее не название CMS или языка, а то, как устроен сайт: есть ли личные кабинеты, административные разделы, формы, API, загрузка файлов, роли пользователей, интеграции и нестандартная логика. Именно это определяет глубину и формат пентеста.
-
Можно ли провести тайный пентест, не оповещая сотрудников? Хочу их проверить.Такой сценарий возможен, но он должен быть заранее согласован с заказчиком и оформлен в понятных рамках. Обычно речь идет не о тайном пентесте сайта в чистом виде, а о проверке реакции сотрудников, администраторов или службы ИБ на определенные действия: например, на попытку входа, фишинг, подозрительную активность или работу с доступами.
Здесь очень важно не выходить за рамки дозволенного. Нужно заранее определить, кого можно затрагивать, а кого нет, какие действия допустимы, какие системы нельзя трогать, как останавливаются работы, если возникает риск для бизнеса, и кто со стороны заказчика знает о проверке и может ее остановить.
Если задача — именно проверить сотрудников, это лучше оформлять как отдельный сценарий с согласованными условиями, а не как обычный пентест сайта.
Наверх
Напишите нам и эксперты САЙБЕР Бизнес Консалтинг проконсультируют по услугам.