ОЦЕНКА ЗАЩИЩЕННОСТИ ВЕБ-ПРИЛОЖЕНИЙ С ИСПОЛЬЗОВАНИЕМ ПОЗИТИВНОЙ МОДЕЛИ ВЕБ-ПРИЛОЖЕНИЙ

DIAGNOSTIC ASSESSMENT METHODOLOGY FOR CONTROL COMPLETENESS OF A POSITIVE SECURITY MODEL IN A REST/API APPLICATION

Lampiev Aleksandr Evgenyevich

Master’s student, Department of Automation and Telemechanics, Perm National Research Polytechnic University,

Russia, Perm

АННОТАЦИЯ

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

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

Апробация выполнена на OWASP crAPI с использованием зафиксированной версии M0, контрольного повтора M0-R и минимальной M1-итерации. В M0-R все 12 позитивных и 12 негативных сценариев получили наблюдаемый след; результаты интерпретировались через подтверждённое, частичное, ограниченно подтверждённое и ошибочно сопоставленное покрытие. M1 показала возможность точечных уточнений без ретроспективного изменения M0. Результаты подтверждают применимость методики в контекстном смысле, не доказывая абсолютную защищённость приложения и не оценивая эффективность конкретного WAF.

ABSTRACT

The article presents a methodology for diagnostic assessment of REST/API-oriented web application security in which the positive security model is treated as the object of verification. The problem is not limited to observing whether a request was blocked, passed or resulted in an error; it is necessary to identify the expected control module, the predefined reaction and the evidence confirming it.

The methodology shifts the focus from detecting isolated vulnerabilities to assessing the control completeness of selected attack classes and deviations from permitted behavior. It was tested on OWASP crAPI using the fixed M0 model version, the M0-R control rerun and a minimal M1 iteration. The M0-R results showed observable evidence for all 12 positive and 12 negative scenarios, while M1 demonstrated that several diagnostic discrepancies can be transformed into targeted model refinements without retroactively changing M0.

Ключевые слова: REST/API-приложение; позитивная модель безопасности; модули контроля; ожидаемое покрытие; фактическое покрытие; диагностический профиль; ложноположительное срабатывание; ложноотрицательный результат; OWASP crAPI.

Keywords: REST/API application; positive security model; control modules; expected coverage; actual coverage; diagnostic profile; false positive; false negative; OWASP crAPI.

1. Введение

В REST/API-ориентированных приложениях оценка защищённости уже не может держаться только на разборе отдельного HTTP-запроса. URI, метод и набор параметров дают внешнюю оболочку действия; реальная допустимость определяется ролью пользователя, состоянием сессии, принадлежностью объекта, местом операции в бизнес-процессе и предшествующей последовательностью вызовов. Один и тот же формально корректный запрос в одном контексте остаётся штатным, а в другом превращается в отклонение от допустимого поведения.

Именно здесь позитивная модель безопасности становится методически полезной.

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

Существующие подходы к оценке защищённости веб-приложений — OWASP WSTG, OWASP ASVS, NIST SP 800-115, PTES, модельно-ориентированное тестирование безопасности, оценка покрытия REST API, защита с учётом сведений об угрозах (threat-informed defense) обоснование безопасности (security assurance) — дают важную базу: техники тестирования, требования, процедурную дисциплину, критерии покрытия и логику подтверждающих данных [1-12]. Но их объект оценки иной. Они не выделяют прикладной слой, где объектом покрытия становятся именно модули позитивной модели безопасности REST/API-приложения.

Цель статьи — представить методику диагностической оценки полноты контроля позитивной модели безопасности REST/API-приложения и показать результаты её апробации на OWASP crAPI. Речь не идёт о полном тестировании на проникновение и не о сравнительном испытании эффективности конкретного WAF. В фокусе находится переход от сценария и ожидаемого покрытия к фактическому покрытию, диагностическому статусу и рекомендации по уточнению модели.

2. Связанные подходы и исследовательский пробел

OWASP WSTG даёт язык тестовых воздействий и сценариев проверки веб-приложений [1]. OWASP ASVS задаёт требования к техническим механизмам безопасности [2]. NIST SP 800-115 и PTES дисциплинируют процесс технической оценки: подготовку, выполнение, фиксацию результатов и оформление выводов [3, 4]. Всё это необходимо, но для настоящей задачи недостаточно.

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

Для REST/API-приложений особое значение имеют исследования, связанные с фаззингом REST API, автоматизированной генерацией тестовых сценариев и оценкой покрытия API. Так, Restats демонстрирует возможность оценки покрытия REST API относительно спецификации и наблюдаемого взаимодействия [6]. Однако в подобных подходах покрытие относится преимущественно к API-спецификации, тестовым сценариям или наблюдаемым запросам, тогда как в настоящей работе объектом покрытия выступают модули контроля позитивной модели безопасности.

Исследования позитивных моделей безопасности и WAF показывают, что допустимое поведение приложения может быть формализовано и использовано для фильтрации запросов [7, 8]. Однако сами по себе такие работы чаще отвечают на вопрос построения или применения модели, а не на вопрос диагностической оценки её полноты. Близкую методическую логику дают подходы, ориентированные на покрытие, сведения об угрозах и подтверждающие данные. Так, модельно-ориентированное тестирование безопасности использует критерии покрытия применительно к моделям и требованиям [9], подходы на основе MITRE ATT&CK сопоставляют атакующие техники с защитными механизмами [10, 11], а обоснование безопасности связывает утверждения о защищённости с подтверждающими данными [12].

И всё же объект оценки отличается.

В перечисленных направлениях объектом покрытия выступают требования безопасности, тестовые модели, техники MITRE ATT&CK, инфраструктурные защитные механизмы или утверждения о защищённости. В настоящей работе объект иной: оценивается полнота контроля отклонений от допустимого поведения модулями позитивной модели безопасности REST/API-приложения. Поэтому исследовательский пробел находится между внешним знанием об атаках и внутренней структурой позитивной модели: нет прикладной процедуры, которая переводит класс атаки в отклонение от допустимого поведения, связывает его с уровнем модели, задаёт ожидаемое покрытие и проверяет это ожидание по фактическим данным.

3. Предлагаемая методика

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

В модели выделяются шесть уровней: структурный, параметрический, ролевой, сессионный, сценарный и поведенческий. Структурный уровень описывает, URI и HTTP-методы; параметрический — типы, форматы и ограничения параметров; ролевой — допустимые операции для ролей и объектов; сессионный — состояние и согласованность сессионного контекста; сценарный — допустимые последовательности действий; поведенческий — частоту, интенсивность и распределение операций.

Методика начинается с принципиального допущения: атака рассматривается как частный случай отклонения от допустимого поведения. Так, инъекционная полезная нагрузка интерпретируется как параметрическое отклонение, BOLA/IDOR — как ролевое или сессионное отклонение, обход предусмотренной последовательности действий (workflow bypass) — как сценарное отклонение, а переборная активность — как поведенческое отклонение. За счёт этого внешние классификации атак [13, 14] не переносятся в модель механически, а связываются с конкретными уровнями позитивной модели.

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

Таблица 1.

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

4. Метрики и диагностические статусы

Для негативного сценария Si ожидаемое покрытие задаётся множеством модулей Mexp(Si), которые должны обнаружить соответствующее отклонение. Фактическое покрытие задаётся множеством Mfact(Si), реакция которых подтверждена журналом, событием, таблицей сценария или иным воспроизводимым источником данных. При достаточных подтверждающих данных полнота контроля может быть представлена как Cneg(Si) = |Mfact(Si) ∩ Mexp(Si)| / |Mexp(Si)|.

Но Cneg(Si) нельзя сводить только к арифметике.

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

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

Таблица 2.

Рабочие диагностические статусы результата

5. Апробация методики на OWASP crAPI

В качестве экспериментального объекта выбрано OWASP crAPI. Выбор обусловлен методической пригодностью: crAPI является API-first приложением и ориентировано на API Security Top 10. В нём представлены API-запросы, объектный доступ, аутентификация, сессионный контекст, параметры, бизнес-процессы и частотные сценарии.

crAPI используется не как объект полного тестирования на проникновение. Его роль уже: проверить цепочку методики в прикладной среде — REST/API, классы атак, отклонения от допустимого поведения, уровни позитивной модели, модули контроля, ожидаемое покрытие, фактическое покрытие, диагностический статус и последующее уточнение модели.

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

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

Первичный P/N-прогон дал полезный, но неоднородный результат: часть сценариев имела технические ошибки, 504-ответы, отсутствие отдельного события детектора или неполные подтверждающие данные. Поэтому был выполнен контрольный повтор M0-R. Он не изменял M0, но усиливал фиксацию подтверждающих данных: сценарии выполнялись в трёх повторах, результаты агента сопоставлялись с журналами WAF и архивом подтверждающих данных.

Таблица 3.

Сводные результаты M0-R

M0-R не следует читать как доказательство полного покрытия. Он показывает другое: процедура устойчива, все сценарии наблюдаемы, но часть результатов остаётся частичной или ограниченно подтверждённой из-за неполной раскрытости внутренних событий модулей контроля. HTTP-реакция или транзакция WAF сами по себе не доказывают срабатывание конкретного ожидаемого модуля.

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

Минимальная M1-итерация включала 13 сценариев: 5 позитивных и 8 негативных. В пределах выбранного подмножества улучшение относительно M0-R было зафиксировано в трёх зонах, прежде всего за счёт устранения части конфликтов сопоставления. При этом M1 не дала искусственно безупречной картины: отдельные ошибочные сопоставления сохранились, а подтверждающие данные по поведенческим детекторам остались ограниченными. Это позволяет рассматривать M1 не как полное исправление модели, а как проверку итерационного механизма уточнения.

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

6. Обсуждение результатов и ограничений

Полученные результаты показывают добавленную ценность методики по сравнению с обычной фиксацией результата тестового запроса. В логике OWASP WSTG или PTES результатом стали бы отдельные успешные или неуспешные проверки. В логике ASVS фиксировалось бы соответствие требованию. В логике ATT&CK/CAPEC сценарии можно было бы связать с классами атак. Предлагаемая методика добавляет другой слой: какое ожидаемое покрытие было задано для модулей позитивной модели, какое фактическое покрытие наблюдалось и почему результат получает именно этот диагностический статус.

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

Ограничения эксперимента также входят в результат, а не маскируются. Апробация выполнена на одном REST/API-приложении и не доказывает универсальную применимость методики. M0 заранее ограничивает область формализации: сценарии, модули, критерии и границы оценки фиксируются до основного прогона, а всё, что не входит в M0, не используется для вывода о защищённости приложения в целом. Кроме того, CSV-выгрузка и журналы WAF не всегда раскрывают событие конкретного модуля, сопоставленную цепочку действий, счётчик детектора или накопительный интервал; HTTP 400/500 не засчитывается как покрытие без связи с ожидаемым модулем контроля.

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

Сравнительно с близкими подходами предлагаемая методика даёт не отдельный факт выполнения теста, не простое соответствие требованию и не покрытие API-спецификации, а диагностический статус ожидаемого и фактического покрытия модулей позитивной модели. Именно это отличает её от WSTG, ASVS, MBST, ATT&CK/CAPEC и security assurance.

7. Заключение

В статье представлена методика диагностической оценки полноты контроля позитивной модели безопасности REST/API-ориентированного веб-приложения. Её вклад состоит в формализации процедуры, связывающей класс атаки, тип отклонения от допустимого поведения, уровень позитивной модели, модуль контроля, ожидаемое покрытие, фактическое покрытие, диагностический статус и последующее уточнение модели.

Апробация на OWASP crAPI показала, что методика даёт не только бинарный результат выполнения сценария, но и диагностический профиль покрытия. Контрольный повтор M0-R подтвердил воспроизводимость выполнения 12 позитивных и 12 негативных сценариев в трёх повторах, сохранив неоднородность фактического покрытия: подтверждённые результаты, ограниченно подтверждённые результаты, частичное покрытие и ошибочные сопоставления. Минимальная M1-итерация показала возможность точечного уточнения модели по части выявленных расхождений без ретроспективного изменения M0.

Гипотеза исследования подтверждается в контекстном смысле. В пределах зафиксированной модели M0, контрольного повтора M0-R, ограниченной M1-итерации, выбранных сценариев и доступных источников подтверждения методика позволяет связать ожидаемое покрытие с фактическими наблюдаемыми реакциями, отделить подтверждённые результаты от неопределённых и сформировать проверяемые рекомендации по уточнению позитивной модели. Но граница вывода сохраняется: результаты не доказывают универсальную защищённость приложения и не являются оценкой эффективности конкретного WAF как продукта.

Список литературы:

1. OWASP Foundation. OWASP Web Security Testing Guide (WSTG) Project [Электронный ресурс]. URL: https://owasp.org/www-project-web-security-testing-guide/ (дата обращения: 31.05.2026).
2. OWASP Foundation. OWASP Application Security Verification Standard (ASVS) Project [Электронный ресурс]. URL: https://owasp.org/www-project-application-security-verification-standard/ (дата обращения: 31.05.2026).
3. Scarfone K., Souppaya M., Cody A., Orebaugh A. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology, 2008. DOI: 10.6028/NIST.SP.800-115.
4. The Penetration Testing Execution Standard. PTES Technical Guidelines [Электронный ресурс]. URL: https://pentest-standard.readthedocs.io/en/latest/ (дата обращения: 31.05.2026).
5. Godefroid P., Lehmann D., Polishchuk M. RESTler: Stateful REST API Fuzzing. Proceedings of the 41st International Conference on Software Engineering (ICSE), 2019.
6. Corradini D., Zampieri A., Pasqua M., Ceccato M. Restats: A Test Coverage Tool for RESTful APIs. arXiv:2108.08209, 2021.
7. Bockermann C., Apel M., Meier M. Automated Creation of Understandable Positive Security Models for Web Applications // Proceedings of the 6th IEEE International Conference on Pervasive Computing and Communications Workshops. 2008.
8. Yaacob A. H., Kiah M. L. M., Zaidan B. B., Zaidan A. A. Moving Towards Positive Security Model for Web Application Firewall // International Journal of Computer and Information Engineering. 2012. Vol. 6, No. 12.
9. Schieferdecker I., Grossmann J., Schneider M. Model-Based Security Testing. arXiv:1202.6118, 2012.
10. MITRE. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge [Электронный ресурс]. URL: https://attack.mitre.org/ (дата обращения: 01.06.2026).
11. Dosunmu A. A., Ogundele P. O. Threat Informed Defence Engineering Models for Measuring Security Control Effectiveness at Scale // International Journal of Advanced Multidisciplinary Research and Studies. 2024. DOI: 10.62225/2583049X.2024.4.6.5526.
12. Shukla A., Katt B., Nweke L., Yeng P., Weldehawaryat G. System Security Assurance: A Systematic Literature Review // Computer Science Review. 2022. DOI: 10.1016/j.cosrev.2022.100496.
13. OWASP Foundation. OWASP API Security Top 10 — 2023 [Электронный ресурс]. URL: https://owasp.org/API-Security/editions/2023/en/0x00-header/ (дата обращения: 31.05.2026).
14. MITRE. CAPEC: Common Attack Pattern Enumeration and Classification [Электронный ресурс]. URL: https://capec.mitre.org/ (дата обращения: 31.05.2026).