Собеседование на пентестера веб-приложений: почему бизнес-логика важнее XSS

На собеседовании на позицию junior пентестера веб-приложений мне дали кейс: интернет-магазин с корзиной, оплатой и доставкой. «Какие уязвимости будешь искать?» — спросил тимлид. Я уверенно перечислил: XSS в полях формы, SQL-инъекцию в поисковой строке, CSRF при смене пароля. Интервьюер кивал. Потом спросил: «А что по бизнес-логике?» Десять секунд тишины. Я промямлил что-то про «проверку прав доступа» и получил вежливое «мы вам перезвоним». Не перезвонили. Две недели подготовки, полсотни задач по инъекциям, вызубренный OWASP Top 10 (десятка наиболее критичных рисков веб-приложений по классификации OWASP) — и ни разу не задумался, как ломается сам бизнес-процесс покупки.

Почему вопросы про бизнес-логику заваливают кандидатов на собеседовании пентестера

Типичная подготовка к собеседованию пентестера: открыть список «50 вопросов по ИБ», вызубрить разницу между симметричным и асимметричным шифрованием, потренировать SQL-инъекции на DVWA (Damn Vulnerable Web Application — специально уязвимое приложение для обучения), пройти пару комнат на TryHackMe. Необходимый минимум — но он покрывает ровно ту часть работы, которую можно автоматизировать. Сканер найдёт Reflected XSS или пропущенные security headers. Интервьюеру интересно другое: умеет ли кандидат думать как атакующий, когда сканер бесполезен.

В Angara Security формулируют прямо: «анализ веб-приложений — это нечто большее, чем ставить кавычки и <script>alert(1)</script> в веб-формы». А Tib3rius в своём сборнике web appsec interview questions задаёт вопрос в лоб: «Как тестирование уязвимостей бизнес-логики отличается от тестирования XSS, SQLi и подобных?» Разница принципиальная. Для XSS есть cheat sheet с сотней пэйлоадов, для SQLi — sqlmap. Для бизнес-логики нет словаря атак. Есть только понимание, как должен работать процесс и что случится, если нарушить последовательность шагов.

По данным Verizon DBIR 2025, 26% всех подтверждённых утечек данных связаны с веб-атаками. Существенная часть из них — не инъекции, а нарушения контроля доступа и эксплуатация недокументированных состояний приложения. Интервьюеры это знают.

Вопросы по бизнес-логике — фильтр между кандидатом, который умеет запускать инструменты, и кандидатом, который понимает, что ломает. На форуме Codeby та же картина: «Кандидаты готовятся не к тому. Зубрят определение модели OSI, но не могут объяснить, на каком уровне работает их любимый сниффер.»

Уязвимости бизнес-логики: что скрывается за термином

Уязвимости бизнес-логики (business logic vulnerabilities) — дефекты в проектировании или реализации приложения, которые позволяют атакующему нарушить предусмотренный сценарий использования. Термин звучит абстрактно, но за ним конкретные вещи: купить товар за отрицательную цену, пропустить этап подтверждения заказа, применить промокод дважды, перевести деньги со счёта другого пользователя через подмену идентификатора.

PortSwigger (разработчик Burp Suite — главного инструмента для ручного тестирования веб-приложений) объясняет корневую причину так: «команды разработки делают ошибочные предположения о том, как пользователи будут взаимодействовать с приложением». Разработчик предполагает, что цена товара берётся с сервера и клиент не может её изменить — но забывает проверить, что значение price в POST-запросе совпадает с ценой в базе данных. Вот тебе и уязвимость без единой кавычки в пэйлоаде.

В OWASP Top 10 2021 уязвимости бизнес-логики не выделены отдельной категорией, но пересекаются сразу с несколькими:

Ключевое отличие от технических уязвимостей: бизнес-логику невозможно протестировать автоматическим сканером. Ни Acunetix, ни Burp Scanner, ни Nuclei (движок для YAML-шаблонов проверки уязвимостей) не знают, что промокод в конкретном интернет-магазине можно применить четыре раза подряд — для этого нужно понимать правила именно этого бизнеса. PortSwigger прямо указывает: «Уязвимости бизнес-логики часто невидимы для тех, кто не ищет их целенаправленно. Их выявление требует человеческого понимания предметной области. Это делает их отличной целью для bug bounty и ручного тестирования.»

Вопросы на собеседовании пентестера веб-приложений по бизнес-логике

Из собственного опыта (включая тот провал) и анализа вопросов из сборника Tib3rius — три группы, на которых чаще всего горят кандидаты на junior пентестер собеседование.

Race condition в платёжных операциях

Вопрос: «Как бы ты протестировал корзину интернет-магазина на race condition?»

Race condition (состояние гонки) — ситуация, когда два или более запроса обрабатываются параллельно и результат зависит от порядка их выполнения. Если проще: пользователь нажимает «Оплатить» один раз, но запрос дублируется, и деньги списываются дважды — или наоборот, заказ создаётся без списания.

Слабый ответ: «Отправлю запрос на оплату два раза подряд.» Это проверяет только повторную отправку, но не параллельную обработку. Разница критична.

Сильный ответ: «Перехвачу HTTP-запрос оплаты в Burp Suite, отправлю его в Turbo Intruder (расширение для массовой параллельной отправки запросов) с 10–20 одновременными копиями. Буду смотреть, создался ли один заказ или несколько. Отдельно проверю, можно ли применить промокод дважды, отправив два запроса применения одновременно. Для защиты от race condition сервер должен использовать атомарные транзакции с блокировкой строки в БД, а не проверять баланс и списывать в два отдельных SQL-запроса.»

Tib3rius в вопросе #49 своего сборника выделяет race conditions как отдельный тип уязвимостей в веб-приложениях — на собеседовании ожидается конкретный сценарий эксплуатации, а не книжное определение.

IDOR в контексте бизнес-процессов

Вопрос: «Чем устранение IDOR отличается от других уязвимостей контроля доступа?»

IDOR (Insecure Direct Object Reference) — обращение к объекту (заказу, профилю, файлу) по прямому идентификатору без проверки, принадлежит ли объект текущему пользователю. Простой пример: GET /api/orders/1234 возвращает чужой заказ, если подставить чужой ID.

Tib3rius формулирует суть в вопросе #10: при IDOR пользователь имеет доступ к самой функциональности (просмотр заказов), но не должен иметь доступа ко всем объектам через неё. Поэтому исправление — не запрет доступа к эндпоинту, а проверка принадлежности конкретного ресурса текущему пользователю.

Слабый ответ: «Заменю ID на чужой и посмотрю, что вернётся.» Описание тестирования, но не понимание механики проблемы.

Сильный ответ: «IDOR — не про закрытие эндпоинта, а про привязку объекта к сессии. В middleware сервера нужно сравнивать owner_id объекта с user_id из JWT-токена. Тестирую через два аккаунта: создаю заказ от пользователя A, пытаюсь получить его данные от пользователя B. Если приложение использует инкрементальные числовые ID — перебор тривиален. UUID усложняет перебор, но если UUID утекает через другой эндпоинт — проблема та же. Отдельно проверяю: удаление и модификацию чужих объектов, не только чтение.»

Это напрямую относится к A01:2021 Broken Access Control в OWASP Top 10 — по их данным, 94% приложений содержат ту или иную форму нарушения контроля доступа.

Манипуляция workflow и обход этапов

Вопрос: «Опиши, как можно нарушить последовательность шагов в процессе оформления заказа.»

Суть тестирования бизнес-логики веб-приложений. Приложение предполагает, что пользователь идёт по шагам: выбор товара → ввод адреса → подтверждение → оплата. Но HTTP не хранит состояние сам по себе (это stateless-протокол). Если сервер не проверяет, что предыдущий шаг завершён, можно перейти к финальному шагу, пропустив оплату.

Сценарий атаки:

1. Положить товар в корзину: POST /cart/add
2. Пропустить шаги ввода адреса и оплаты
3. Сразу отправить запрос подтверждения: POST /orders/confirm
4. Если сервер не проверяет статус оплаты — заказ создан бесплатно

PortSwigger указывает: «Злоумышленник может завершить транзакцию без прохождения предусмотренного workflow покупки.» Интервьюер проверяет, понимает ли кандидат, что API-эндпоинты можно вызывать в произвольном порядке и каждый шаг должен валидировать состояние предыдущего на сервере.

Ещё один вариант — манипуляция ценой. В Burp Suite перехватываем запрос добавления товара в корзину и меняем параметр quantity на отрицательное значение. Если сервер не проверяет знак числа, итоговая сумма заказа уменьшается. Mass Assignment (вопрос #23 у Tib3rius) — смежная техника: добавить в POST-запрос поле role: "admin" или price: 0 и проверить, примет ли их сервер.

Тестирование бизнес-логики: делай раз, делай два, делай три

Методология ниже — минимум, который стоит отработать до собеседования. Что понадобится: Burp Suite Community Edition (бесплатная версия — для базовых тестов хватает), браузер с настроенным прокси, тестовое приложение. Подойдут лабы PortSwigger Web Security Academy — бесплатные, запускаются прямо в браузере.

Шаг 1. Составь карту бизнес-процессов

Пройди весь процесс как обычный пользователь: регистрация → авторизация → добавление товара → оформление заказа → оплата → подтверждение. В Burp Suite включи перехват (вкладка Proxy → Intercept is on) и просматривай каждый HTTP-запрос. На этом шаге ищешь не уязвимости, а ответ на вопрос: какие шаги приложение считает обязательными и какие параметры передаются между ними?

Ожидаемый результат: список из 5–15 HTTP-запросов. Для каждого записывай: URL, метод (GET/POST/PUT), ключевые параметры (IDs, токены, суммы, статусы). Если запрос возвращает JSON — обрати внимание на поля, которые выглядят как флаги состояния: is_paid, status, step. Именно их ты будешь ломать на следующем шаге.

Шаг 2. Нарушь последовательность

Бери каждый шаг и проверяй: что будет, если его пропустить? Повторить? Выполнить в другом порядке? В Burp Repeater отправляй запрос подтверждения заказа без предварительного запроса оплаты. Меняй значения: цену товара, количество (попробуй 0, -1, 999999), ID промокода.

Ожидаемый результат: таблица «пропущен шаг X → ответ сервера Y». Каждый HTTP 200 при пропущенном критическом шаге — потенциальная уязвимость. HTTP 403 или 400 с сообщением «шаг оплаты не завершён» — признак корректной валидации.

Шаг 3. Проверь граничные значения и параллелизм

Для каждого числового параметра проверь граничные случаи: ноль, отрицательное значение, число с плавающей точкой (1.5 единицы товара), строку вместо числа. Для проверки race condition — используй Turbo Intruder в Burp Pro или отправь несколько параллельных запросов через curl:

# Параллельная отправка 5 запросов на применение промокода
for i in {1..5}; do
  curl -s -X POST https://target/api/promo/apply \
    -H "Cookie: session=YOUR_SESSION" \
    -d '{"code":"DISCOUNT50"}' &
done; wait

Если промокод применился больше одного раза — race condition подтверждён. Если товар с отрицательной ценой уходит в корзину — дефект валидации. В обоих случаях записывай точный запрос и ответ — на собеседовании это и есть «покажи, как тестировал».

Подготовка к собеседованию пентестер: чек-лист по бизнес-логике

Ошибки на собеседовании в ИБ чаще связаны не с незнанием терминов, а с неумением применить знания к конкретному кейсу. Чтобы карьера в пентесте не остановилась на первом собеседовании — план на неделю до интервью.

Теория (2–3 дня):

• Раздел Business Logic Vulnerabilities в PortSwigger Web Security Academy — с бесплатными лабами в браузере
• OWASP Testing Guide, раздел Testing for Business Logic (WSTG) — описывает 9 тест-кейсов (от BL-001 до BL-009: проверка валидации данных, целостности workflow, лимитов на использование функций)
• 5–7 вопросов Tib3rius по web appsec: #10 (IDOR), #12 (business logic), #23 (mass assignment), #49 (race conditions) — напрямую по теме

Практика (2–3 дня):

• Пройти минимум 3 лабы PortSwigger категории Business logic vulnerabilities — они нарастают по сложности от обхода ценовой проверки до многоступенчатых атак на workflow
• Для каждой лабы записать: какой workflow нарушен, какое предположение разработчика оказалось ошибочным, что нужно исправить на серверной стороне. Это не формальность — именно эти записи станут твоими примерами на собеседовании
• Протестировать OWASP Juice Shop (открытое уязвимое приложение) — найти хотя бы один бизнес-процесс, который можно сломать

Перед самим собеседованием:

• Подготовить 2–3 конкретных примера найденных уязвимостей бизнес-логики (из лаб или CTF) с описанием workflow, вектора атаки и рекомендации по исправлению
• Уметь объяснить, почему автоматический сканер не находит эти уязвимости, а ручной WAPT-процесс (Web Application Penetration Testing — тестирование на проникновение веб-приложений) — находит
• Помнить: интервьюер хочет услышать сценарий атаки в контексте конкретного бизнес-процесса, а не определение из учебника

После того провала я провёл полтора десятка технических интервью уже с другой стороны стола — как интервьюер на junior и mid позиции. Закономерность подтвердилась: восемь из десяти кандидатов отлично отвечают на вопросы про XSS, SQLi и CSRF, но впадают в ступор при любом вопросе, который требует придумать атаку, а не вспомнить пэйлоад из шпаргалки. Проблема не в людях — в том, как индустрия готовит джунов. CTF-площадки тренируют технические навыки: вот флаг, вот пэйлоад, вот победа. Реальный пентест веб-приложений на 60% состоит из анализа того, как приложение должно работать, и на 40% — из попыток заставить его работать иначе.

Тот провал научил меня правилу, которое до сих пор транслирую кандидатам: перед тем как тестировать приложение, разберись в его бизнесе. Не в коде и не в стеке — в том, что приложение делает для пользователя и какие правила этого процесса разработчик мог не реализовать на серверной стороне. Навык, который не прокачивается решением задач по SQLi — он требует работы с реалистичными бизнес-процессами и понимания, как стать пентестером, который видит дальше сканера. На WAPT эту цепочку — от разведки бизнес-логики до эксплуатации race condition — проходят в нескольких модулях с лабами.