Технические находки
С заметками о валидации — воспроизводимо и без гипотез инструментов.
Услуга · Web и API
То, чем бизнес на самом деле рискует
Проверка веб-приложений, клиентских кабинетов, серверных интерфейсов (API) и интеграций на практические риски — там, где сканер почти бессилен, а логику авторизации и бизнес-процесса нужно проверять руками.
Активная фаза начинается только после письменного разрешения владельца приложения и в согласованных границах (объём работ и правила взаимодействия). Сайт статичен и не принимает учётные данные.
ХОД_РАБОТЫ
Жизненный цикл проверки
Ручное тестирование с валидацией каждой находки.
- 01 Определение объёма работ
- 02 Модель тестовых учётных записей
- 03 Ручное тестирование
- 04 Валидация находок
- 05 Рекомендации по устранению
Когда нужна
Когда бизнес зависит от веб-приложений, кабинетов, панелей, серверной части мобильного приложения или API.
Объём
Аутентификация и сессии, контроль доступа, бизнес-логика, злоупотребление API и интеграциями.
Стандарты
OWASP WSTGASVSAPI Top 10
Режимы
Без учётных записей, с учётными записями, несколько ролей — режимы исполнения одной услуги.
01 — Приложение обязано быть доступным
Каждая легитимная дверь — интерфейс для злоупотребления
Сетевой периметр можно спрятать за фильтрами и VPN, но приложение обязано быть доступным: клиент должен войти, партнёр — вызвать метод интеграции, мобильное приложение — синхронизировать данные. Сканер здесь почти бессилен: логические ошибки авторизации и злоупотребление контрактом API не имеют сигнатур.
Атакующий не обходит защиту — он пользуется приложением так, как разработчики не ожидали: подставляет чужой идентификатор, вызывает забытый метод, перебирает объекты через интерфейс, который честно отвечает на каждый запрос.
Тот же результат, что и «взлом»
Массовая выгрузка клиентских данных, изменение чужих транзакций, обход платёжной логики — без единой «взломанной» системы, только через легитимные запросы.
02 — Что входит в проверку
Пять взаимодополняющих областей
Основой служат три документа OWASP: WSTG задаёт состав проверок, ASVS — планку требований, API Security Top 10 — классы рисков интерфейсов. Раскройте область, чтобы увидеть детали.
Логика входа, восстановления доступа и смены пароля, устойчивость сессионных механизмов, поведение при параллельных сессиях, работа второго фактора и точки, где его можно обойти архитектурно.
OWASP ASVS
03 — Как проходит работа
Дисциплина исполнения по этапам
01 · Определение объёма работ
Фиксируются границы: домены, среды, версии, интеграции и исключения; временные окна, правила взаимодействия и канал экстренной связи. Активная фаза — только после письменного разрешения (ст. 359 и 363 УК РА).
Режим тестирования
Тестирование без учётных записей отвечает на вопрос «что видит и может посторонний»: экспозиция, аутентификация «в лоб», утечки в ответах.
Это режимы исполнения одной услуги, а не отдельные продукты. Модель тестовых учётных записей согласуется на этапе согласования объёма.
04 — Типичные классы находок
Что находим и что это значит для бизнеса
По каждому классу отчёт связывает техническую суть с конкретным бизнес-риском: чьи данные, какие функции, какой сценарий давления со стороны клиентов, партнёров или регулятора.
F1 Разрывы объектной авторизации (IDOR/BOLA). Доступ к чужим записям через подмену идентификатора — прямой путь к массовой утечке клиентской базы. ВЫС
F2 Слабые места аутентификации и сессий. Захват учётной записи — действия от имени клиента: вывод средств, смена реквизитов, доступ к документам. ВЫС
F3 Ошибки бизнес-логики. Обход лимитов, манипуляция суммами и статусами — потери, которые не видны в журналах как «атака» и потому длятся месяцами. ВЫС
F4 Избыточные данные в ответах API. Интерфейс отдаёт больше, чем показывает экран: скрытые поля становятся утечкой без единой «взломанной» системы. СРЕД
F5 Забытые версии и теневые методы. Старый метод без современных проверок обнуляет защиту нового: атакующий выбирает самую слабую дверь. СРЕД
F6 Слепое доверие между сервисами. Компрометация одной интеграции превращается в компрометацию всех, кто ей верит без собственной проверки. СРЕД
05 — Что вы получаете
Технические находки с планом действий
Не перечень дефектов, а план с приоритетами и понятной связью «дефект → бизнес-риск».
Риск для данных и функций
Что именно под угрозой: чувствительные данные, платёжные функции, роли.
Рекомендации по устранению
Код, конфигурация, контракты API и процессные рекомендации против рецидива.
06 — Устранение и повторная проверка
Чтобы класс проблемы не вернулся в следующем релизе
Немедленно
Исправления кода и конфигурации, закрывающие прямой доступ к чужим данным и функциям.
Ближайший цикл
Корректировки контрактов API, версий и ролевых моделей в плановом релизе.
Системная работа
Процессы разработки, при которых класс дефекта не воспроизводится. Повторная проверка подтверждает результат.
07 — Регуляторный контекст и источники
Для платёжных организаций и операторов электронных денег ЦБ РА подчёркивает ожидания в области кибербезопасности и операционной устойчивости; клиентские кабинеты и платёжные API — первое, на что смотрят и партнёры, и проверяющие. Для поставщиков услуг криптоактивов безопасность платформы — условие доверия.
OWASP Web Security Testing Guide owasp.org ↗ OWASP Application Security Verification Standard owasp.org ↗ OWASP API Security Project owasp.org ↗ NIST SP 800-115 csrc.nist.gov ↗ Требования ЦБ РА к платёжным организациям cba.am ↗ ЦБ РА о поставщиках услуг криптоактивов cba.am ↗ Закон РА «О защите персональных данных» arlis.am ↗
Граница честности
Результаты помогают подготовиться к проверкам и вопросам, но не являются юридическим заключением о соответствии.
Версия и объём работ
Результаты относятся только к согласованной версии и области проверки, а также к моменту её проведения.
08 — Куда дальше
Проверить продукт и интеграции по существу
Обсудим объём работ и модель тестовых учётных записей. Работы ведутся только после письменной авторизации; доступы передаются вне сайта.