Тестирование бизнес-логики на безопасность

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

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

С этой проблемой сталкивается CISO, CTO или руководитель разработки, когда заказывает тестирование бизнес-логики: риск сидит в процессах и правилах, а не в некорректном вводе, поэтому привычные способы определять охват, оценивать стоимость и принимать результаты пентеста здесь работают плохо. Ниже разбираем, что именно проверяет такая работа, как строить охват вокруг бизнес-процессов, как квалифицированный тестировщик проводит её, не нарушая живые операции, и какие доказательства стоит потребовать, прежде чем считать проект завершённым.

Что на самом деле проверяет тестирование бизнес-логики

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

Корректный запрос в неправильном контексте

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

Это меняет сам предмет покупки. Вы платите не за инструмент, который отправит полезные нагрузки в каждый параметр. Вы платите за специалиста, который понимает процесс настолько хорошо, чтобы спросить: «Что будет, если этот шаг пропустить, повторить или запустить наперегонки с другим?» — и затем подтверждает ответ авторизованным тестированием.

OWASP Business Logic Security Cheat Sheet формулирует ту же мысль со стороны защиты: действие может быть синтаксически корректным и при этом нарушать бизнес-процесс или бизнес-инвариант. Его рекомендации по тестированию сводятся к изменению порядка шагов, повторной отправке запросов, параллельному выполнению операций и проверке того, что цены, права и состояние процесса контролируются на сервере, а не принимаются на веру от клиента.

Инвариант как единица работы

Охват удобнее всего описывать через инварианты — утверждения, которые должны оставаться истинными при любой последовательности запросов. «Бронь выше лимита никогда не подтверждается без одобрения руководителя». «Промокод даёт не более одной скидки на компанию». «Сумма возвратов по поездке никогда не превышает оплаченную».

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

Почему состояние процесса живёт в приложении, а не в HTTP

Распространённое упрощение гласит: раз HTTP не хранит состояние, сервер не сохраняет данные сессии между запросами. Это неверно, и ошибка существенна, потому что правильная картина как раз объясняет, откуда берутся логические уязвимости.

Протокол без состояния — не значит сервер без состояния

HTTP не хранит состояние на уровне протокола: каждый запрос понимается сам по себе, и протокол не знает, что третий запрос относится к тому же оформлению заказа, что и второй. Это не мешает серверам хранить состояние. Почти любое реальное приложение так и делает — в серверном хранилище сессий, привязанном к cookie, в записях базы данных, отражающих статус заказа, или в кэше. Cookie и идентификаторы сессии позволяют приложению связывать отдельные запросы с состоянием, которое оно хранит.

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

Где возникают разрывы

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

Конкурентный доступ заслуживает отдельного упоминания. В HTTP есть условные запросы — например, ETag с If-Match, — которые предотвращают потерю обновлений, когда два клиента меняют один ресурс. Операциям с балансом и квотами обычно нужны также атомарные обновления, ограничения уникальности, блокировки строк или ключи идемпотентности. Задача тестировщика — проверить, держится ли защита, когда запросы действительно приходят наперегонки, а не то, упомянут ли механизм в проектной документации.

Почему универсальные сканеры теряют нить

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

Где проходят границы атаки

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

Изменение порядка и пропуск шагов

В гипотетической платформе командировок задуманный процесс таков: черновик, отправка, согласование, подтверждение, выписка. Тестировщик попробует вызвать подтверждение для черновика, повторно отправить уже согласованную бронь с изменённой суммой или повторить согласование после того, как бронь отредактировали. Вопрос каждый раз один: проверяет ли сервер текущее состояние или верит, что клиент пришёл к этому шагу честно?

Повтор и конкурентные запросы

Проверка повтора выясняет, может ли действие, которое должно случиться однажды, случиться дважды: возврат зачислен дважды, разовый бонус получен снова, приглашение принято после отзыва. Конкурентный доступ — более сложный родственник повтора. Два запроса на погашение, отправленные с разницей в миллисекунды, могут оба прочитать «не использован» раньше, чем любой из них запишет «использован».

Какие значения сервер должен проверять самостоятельно

Клиент вправе передать желаемое количество товара или выбрать доступную валюту. Сервер должен проверить допустимость такого выбора: диапазон количества, доступность валюты, ограничения товара и условия операции. А цену, скидку, курс и итог к оплате он рассчитывает по своим доверенным данным, не принимая готовый результат от клиента на веру. Находка возникает, когда изменение входного значения позволяет обойти эти правила — например, получить отрицательный итог или чужую скидку. Исправление должно восстановить соответствующее правило на сервере, а не просто запретить клиенту передавать любые количественные значения.

Где тестирование логики пересекается с контролем доступа

Границы арендаторов и ролей лежат между тестированием логики и классической проверкой авторизации. Подмену идентификатора объекта ради чтения записи другого арендатора обычно относят к нарушению контроля доступа; возможность заявителю одобрить собственный расход чаще относят к логике. Ярлык важен меньше, чем уверенность, что охват покрывает оба случая и никто не считает, что это проверила другая команда. Для продуктов с развитым API методика оценки безопасности REST API показывает, как проверки авторизации на уровне объектов и функций сочетаются с проверками процессов.

Как строить охват вокруг бизнес-процессов

Именно на этапе определения охвата большинство проектов по логике либо получаются, либо нет. Если охват — это список хостов и число эндпоинтов, тестировщик потратит первые дни на то, чтобы восстановить то, что бизнес и так знает.

Что подготовить до начала тестирования

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

Что входит в охват и что за его пределами

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

Ценовые сигналы, которые стоит проверить

Осторожно относитесь к сметам, где тестирование логики оценено только по числу URL или эндпоинтов. Логический риск растёт вместе с количеством процессов, ролей, состояний и операций с деньгами; небольшой API может скрывать сложный механизм согласований, а большой маркетинговый сайт — почти не содержать логики, которую стоит проверять. Смета, игнорирующая процессы, скорее всего, означает обычное сканирование под другим названием.

Если хотите определить такой охват вместе с Pentest.red, удобная отправная точка — тот же список: какие процессы перемещают деньги, выдают права или пересекают границы арендаторов, какие инварианты важны бизнесу, какие среды и тестовые учётные записи доступны и какие доказательства вы ожидаете в конце. Начать этот разговор можно на странице подготовки контура пентеста; объём и формат работ согласуются уже оттуда, а не обещаются заранее.

Как проводится тестирование

NIST SP 800-115, опубликованный в 2008 году, описывает процесс оценки через планирование, выполнение и действия после выполнения; последний этап включает анализ находок, рекомендации по устранению и итоговый отчёт. Это не полная программа тестирования, но его структура этапов хорошо подходит для работы с логикой, если каждый этап опирается на бизнес-модель, а не на вывод инструмента.

Построение модели процесса

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

Атака на каждый инвариант

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

1. Смоделировать процессВместе с владельцем продукта описать участников, состояния, допустимые переходы и места, где затрагиваются деньги, права или необратимые действия.
2. Сформулировать инвариантЗаписать правило, которое должно выполняться всегда, например «промокод даёт не более одной скидки на компанию», в понятных обеим сторонам терминах.
3. Попытаться нарушитьМенять порядок, пропускать, повторять или запускать наперегонки запросы и подменять серверные значения, используя только тестовые учётные записи и синтетические данные.
4. Подтвердить и оценитьНадёжно воспроизвести нарушение и описать влияние в терминах бизнеса: что получает злоумышленник, во что это обходится и кто это заметит.
5. Исправить и закрепитьОбеспечить правило на сервере, повторно проверить исходный путь и его варианты и добавить автоматический регрессионный тест.

Анализ находок в терминах бизнеса

На этапе анализа находки ранжируются не только по технической критичности, но и по влиянию на бизнес. Состояние гонки, позволяющее применить один промокод дважды, в системе оценки уязвимостей может выглядеть незначительным и при этом быть существенным для бизнеса, который выпускает много партнёрских кодов; и наоборот, теоретический обход, требующий учётных данных самого согласующего, может оказаться менее важным, чем кажется на первый взгляд. Отчёт должен объяснять логику оценки, чтобы руководство воспринимало находки как бизнес-риск и вносило их в тот же реестр рисков, что и всё остальное.

Безопасная работа с живыми транзакциями

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

Разрешение, окна и условия остановки

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

Данные, платежи и внешние побочные эффекты

Тестовые данные должны быть синтетическими. Любые действия с внешними последствиями — платежи, письма, SMS, вызовы партнёрских API, проводки, уходящие в бухгалтерию, — нужно изолировать в песочнице или явно согласовывать в каждом случае. Если тестирования в продуктивной среде не избежать, заранее договоритесь, как тестовые транзакции помечаются, отменяются и сверяются.

Тесты конкурентного доступа без побочного ущерба

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

Какие стандарты стоит упоминать и чего они не делают

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

WSTG и ASVS — для прослеживаемости, а не для охвата

В OWASP Web Security Testing Guide 4.2 есть отдельный раздел о тестировании бизнес-логики, и поставщик должен уметь показать, каким его областям соответствуют тестовые сценарии. OWASP ASVS 5.0.0 использует версионированные идентификаторы требований вида v5.0.0-1.2.5, которые позволяют указать в отчёте, какое именно требование и по какой версии проверялось. Фиксация версии важна: нумерация требований меняется между выпусками, и находка со ссылкой на идентификатор без версии через год может стать двусмысленной.

Списки для осведомлённости не задают границу

OWASP Top 10 — документ для повышения осведомлённости, отправная точка для обсуждения, а не граница охвата проекта по логике. Отраслевые рейтинги слабостей, построенные на публичных записях об уязвимостях, естественно выделяют дефекты, которые повторяются во многих продуктах. Логические ошибки часто специфичны для процессов одной организации, поэтому их малая заметность в таких рейтингах не означает низкого риска. Статья не делает утверждений о распространённости логических дефектов; честная позиция такова: их значимость зависит от того, насколько ваше приложение перемещает деньги, выдаёт права или разделяет арендаторов.

Чем пентест не является

Тестирование бизнес-логики — ограниченное по времени и охвату упражнение. Оно может показать, что конкретные инварианты проверялись конкретными способами, и что из этого вышло. Это не сертификация, не аттестация и не гарантия того, что в приложении нет логических дефектов; чистый отчёт не доказывает отсутствия проблем за пределами проверенных процессов или появившихся после тестирования.

Какие доказательства принимать перед закрытием проекта

Ценность проекта по логике видна по тому, что он оставляет после себя. Ниже — проверки, которые стоит применить перед подписанием акта.

Находки и воспроизведение

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

Повторная проверка и регрессия

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

Как выбрать поставщика и периодичность

Вопросы, отличающие тестирование логики от переименованного сканирования

Попросите обезличенный образец отчёта с моделью процесса, проверенными инвариантами и влиянием на бизнес. Спросите, как поставщик строит модель и кто ему нужен с вашей стороны. Узнайте, как он безопасно тестирует гонки, как обращается с побочными эффектами во внешних системах, как находки соотносятся с областями WSTG и версионированными требованиями ASVS и что входит в повторную проверку. Ответы в терминах ваших процессов — лучший признак, чем перечень инструментов. Более широкую методику сравнения описывает материал о том, как сравнивать поставщиков пентеста.

Периодичность в зависимости от экспозиции

Начните с экспозиции. Отдельное тестирование логики оправдано, если приложение перемещает деньги, выдаёт права, разделяет арендаторов или запускает необратимые действия. Если оно в основном отдаёт статический контент, большую часть риска могут покрыть автоматизированные проверки и безопасная конфигурация.

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

Когда решение принято, с Pentest.red можно обсудить, как проверки бизнес-логики встраиваются в более широкий проект по тестированию на проникновение: какие процессы получают глубокую проверку, какие — более лёгкое покрытие и как организована повторная проверка. Всё это определяется исходя из вашего приложения и ограничений, а не из фиксированного пакета.

Итоги

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

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