Информационная безопасность веб-ресурсов долгое время развивалась в формате формальных проверок. Сканер, отчет, список уязвимостей, исправления по приоритетам. Такой подход создает иллюзию контроля, но почти не отражает реальную картину угроз. В реальных инцидентах сайты и веб-сервисы компрометируются не из-за одной "критической" уязвимости, а из-за цепочек слабостей - технических, логических и организационных.
Фреймворк OFWEB security был разработан именно, как ответ на этот разрыв. Его задача - не проверить сайт на соответствие стандарту, а смоделировать поведение реального атакующего, начиная с поверхностной разведки и заканчивая полной цепочкой компрометации, включая людей и процессы, стоящие за веб-ресурсом.
Общая философия OFWEB security
OFWEB security исходит из простого принципа - если веб-ресурс стал целью, реального атакующего не интересует соответствие OWASP, наличие отчета или галочка в чеклисте. Его интересует результат - доступ, контроль, данные или возможность дальнейшего развития атаки. Самая большая проблема сферы информационной безопасности, что сейчас два мира - кибербез и хакеры очень далеки друг от друга, один мир забюрократизирован до невозможного (в инфобезе уже чиновников, которые код никогда не видели, больше, чем реальных аитишников), а другой никогда регуляторики и в глаза не видел - они только кодят и ломают. Естественно гадать тут не надо, какой из миров эффективнее!
Данный фреймворк строится не вокруг уязвимостей как таковых, а вокруг поверхности атаки, логики системы и реальных сценариев эксплуатации. Каждая фаза проверки приближена к тому, как действует реальный противник, а не к тому, как выглядит классический аудит.
Фаза 1. Базовая разведка и проверка минимальной устойчивости
Проверка всегда начинается с самого простого уровня. Это осознанное решение. Реальный атакующий никогда не начнет со сложных техник, если цель сыпется на базовом этапе.
Клиентская сторона и браузер как первая точка входа
Первое, что анализируется - это поведение веб-ресурса в браузере. Консоль разработчика, сетевые запросы, загружаемые скрипты, source maps, cookies, local и session storage. Нас интересуют не косметические ошибки, а утечки внутренней логики.
На этом этапе регулярно обнаруживаются:
- открытые внутренние API
- незащищенные feature-флаги
- hardcoded ключи
- логика авторизации на клиенте
- dev-артефакты в production
Удивительно, но уже здесь многие проекты теряют баллы и фактически становятся уязвимыми без какого-либо сложного exploitation.
OWASP как архитектурная модель, а не чеклист
В рамках OFWEB OWASP используется не как список уязвимостей, а как карта доверия. Проводится анализ, где именно нарушаются границы между пользователем, приложением, сервисами и инфраструктурой.
Проверяются в первую очередь:
- контроль доступа и разграничение ролей
- обработка пользовательского ввода
- управление сессиями и токенами
- CORS-политики и доверие источникам
- обработка ошибок и исключений
- логика переходов между состояниями
Автоматические инструменты применяются, но исключительно как вспомогательный механизм. Любая находка подтверждается вручную и рассматривается в контексте всей архитектуры.
Проверка транспортного уровня и базовой защиты сессий
На этом этапе анализируется TLS-конфигурация, корректность HSTS, cookie-флаги, возможность MITM-атак, а также реальная, а не формальная, защита от CSRF.
Дополнительно проверяются логические CSRF-сценарии, где токен формально присутствует, но не защищает критические действия. Уже на этой фазе становится очевидно, готов ли ресурс к эксплуатации в реальной среде. В большинстве случаев - нет.
Фаза 2. Слепки веб-ресурса и поведенческий анализ
Если сайт выдерживает базовый уровень, OFWEB переходит к более глубокой фазе - моделированию поведения системы.
Создание функционального слепка
Мы сами создаем слепок веб-ресурса, насколько это возможно, фиксируя:
- структуру и маршруты
- динамику состояний
- роли и уровни доступа
- переходы между сценариями
- реакции на ошибки и нестандартные входные данные
Это не статическое копирование, а попытка зафиксировать динамическую модель работы приложения, как ее видит атакующий.
AI-анализ логики и аномалий
Полученные данные анализируются, в том числе с помощью AI-систем, которые помогают выявлять аномалии, повторяющиеся паттерны и несоответствия между слоями приложения.
На этом этапе становится ясно, почему до 95% веб-ресурсов не проходят проверку даже на уровне 6 баллов из 10. Основные причины почти всегда одни и те же: устаревшие библиотеки, не обновленные CMS, уязвимые плагины и слабые процессы управления зависимостями. Особенно часто это наблюдается у WordPress и других массовых платформ, где проблема кроется не в технологии, а в эксплуатации.
Фаза 3. Переход к offensive-мышлению
С этого момента проверка перестает быть аудитом. Мы больше не задаем вопрос “соответствует ли сайт стандарту”. Мы задаем вопрос:
что можно сделать с этим ресурсом, если он стал целью?
Меняется логика, меняются цели, меняется допустимый уровень давления. Нас интересует не отдельная уязвимость, а реальный сценарий эксплуатации.
Фаза 4. Offensive-тестирование веб-ресурса
Эта фаза строится вокруг техник, которые действительно используют атакующие. Ниже 20 ключевых offensive-действий, которые выполняются после прохождения базового стандарта.
- Составление подробной карты атаки - планирование точек входа, включая скрытые, устаревшие и забытые маршруты.
- Атака на бизнес-логику - эксплуатация легитимных сценариев для нарушения экономики, лимитов и ролей.
- Попытки обхода авторизации через состояния, последовательности действий и race condition.
- Работа по API-контрактам с попытками изменения типов, вложенности и комбинаций параметров.
- IDOR-атаки - глубокая проверка доступа к объектам через реальные цепочки.
- State-based атаки - эксплуатация ошибок перехода между состояниями.
- Race condition-атаки - использование параллельных запросов и несинхронизированной логики.
- Сессионно-ориентированные атаки на контексты и управление сессиями.
- Токен-ориентированные атаки с попытками повторного использования временных токенов.
- Использование систем восстановления доступа и атаки на них - forgot password, reset flows, email verification.
- File handling атаки - загрузка, парсинг и обработка файлов.
- SSRF и indirect network access - доступ к внутренним и внешним сервисам через сервер.
- Header-based атаки - abuse доверия к заголовкам и proxy-инфраструктуре.
- Webhook abuse - replay, подмена источников, логические ошибки.
- Third-party интеграции - одно из любимых направлений, чаще других эффективно на высокозащищенных системах, проводятся атаки на OAuth, SSO, платежные системы, аналитику.
- Error-driven exploitation - извлечение логики и данных через ошибки.
- Automation-атаки - обход rate-limit и anti-bot механизмов.
- Data exfiltration сценарии - незаметный и легитимный вывод данных.
- Повышение привелегий - старый как мир метод с попытками перехода от минимальных ролей к расширенным, особенно в системах, где подобные доступы не разделены (большинство классических CMS).
- Full kill-chain моделирование - сборка всех слабостей в реальный сценарий атаки.
Фаза 5. Атакующее тестирование администраторов и техдепартаментов
Ключевое отличие OFWEB security - включение в модель угроз людей и процессов, стоящих за веб-ресурсом и самой информационной безопасностью. Анализируются репозитории, commit history, конфигурации, вакансии, презентации и технические публикации, более того осуществляются попытки пробиться к самим SOC/SIEM системам. Далее моделируются сценарии, в которых атакующий встраивается в технические процессы - деплой, управление ключами, доверие к внутренним операциям, ручные действия в production.
Фаза 6. Сборка полной цепочки атаки
Финальный этап OFWEB - не отчет по уязвимостям, а реалистичная kill-chain, показывающая, как веб-ресурс может быть скомпрометирован от первой точки входа до конечной цели.
Методология OFWEB security
это методология, ориентированная на реальность. Она показывает, что безопасность веб-ресурса определяется не отчетом, а устойчивостью системы, процессов и людей к цепочке атак.
Большинство сайтов небезопасны не потому, что разработчики плохие. А потому что их никогда не проверяли так, как их будут атаковать. OFWEB закрывает этот разрыв.