РУКОВОДСТВО 03 · ВЕБ-ПРИЛОЖЕНИЯ И API
Проверка безопасности API с тестовыми аккаунтами
Для автоматической проверки API подготовьте адреса, тестовые аккаунты, известные объекты и ожидаемые права. Действующий токен подтверждает личность, но не разрешение читать любой заказ. Scantelio выполняет поддерживаемые сценарии в заданной области и бюджете. Авторизованные профили доступны в платных тарифах; активные изменения проверяются на staging с отдельным согласием.
Подготовить проверку APIПонадобятся вход, подтверждение владения и согласие. Для авторизованных сценариев, мониторинга и CI нужен Pro или Business.
Содержание
Краткий ответ и условия проверки
Для API нужны контракт запросов и ожидаемые права. OpenAPI описывает входные данные, но не определяет владельца каждого объекта.
Схема API, два ограниченных тестовых аккаунта, тестовые объекты и ожидаемые роли.
| Проверка | Ожидаемое доказательство |
|---|---|
| Действие | Повторите разрешённое чтение от другого аккаунта; сравнивайте содержимое, а не только HTTP-статус. |
| Положительный и отрицательный контроль | Уязвимый пример даёт доказательство, исправленный — нет. Успешный контрольный запрос подтверждает доступность цели. |
| Блокировка или недостающие данные | Отметьте проверку как пропущенную или незавершённую с причиной. Отсутствие аккаунта, ответ WAF и таймаут не означают отсутствие проблем. |
| После исправления | Повторите проверку той же цели, аккаунта и объекта. Сохраните исходное доказательство и новый результат; покрытие ограничено выполненными сценариями. |
Продолжить: Посмотреть пример отчёта
Продолжить: Покрытие и необходимые данные
Какие проблемы проверяются
Разделите четыре вопроса: доступна ли функция, разрешён ли объект, соблюдается ли граница организации и можно ли изменить защищённое поле. Скачивание счёта и экспорт заказов проверяются отдельными маршрутами. Диагностика JWT и ограничений запросов даёт вывод только в заданных условиях. SQLi и XSS относятся к поддерживаемым активным сценариям, а не к обещанию проверить любую форму и каждый браузерный путь.
Что подготовить владельцу
Подготовьте URL компонента, среду, OpenAPI либо известные операции, два аккаунта и синтетические записи. Для входа доступны поддерживаемые настройки Bearer, API key, cookies и JSON login; конкретный способ должен пройти диагностику. Сессия должна работать достаточно долго или иметь настроенное обновление. Не загружайте настоящий .env и не выдавайте универсальные production-права: тесту нужны ограниченные полномочия на известные данные.
Первичные источники: OWASP: REST Security
Продолжить: IDOR и BOLA: как проверить доступ к чужим данным в своём API
Как задать ожидаемые права
Для каждой операции запишите, кто обращается к какому объекту и какой результат разрешён. Учтите публичные документы и доступ по приглашению.
Чтение: чей объект попал в ответ
Создайте по документу для A и B с разными вымышленными маркерами. Сначала убедитесь, что B видит свой маркер. Затем запросите тот же документ от имени A: важен и статус, и отсутствие маркера B в теле ответа. Повторите для скачивания и экспорта, если они доступны.
Запись: изменилось ли состояние объекта
На тестовом объекте B запомните исходное значение поля. Попробуйте изменить его от имени A, затем снова прочитайте от имени B. Даже при ответе с ошибкой изменение поля означает, что запрет не сработал.
| Контекст | Объект | Метод | Ожидание |
|---|---|---|---|
| A | doc-a | GET | 200 |
| A | doc-b | GET | 403 |
| B | doc-b | GET | 200 |
| B | doc-a | GET | 403 |
| guest | doc-a | GET | 200 |
| guest | doc-b | GET | 403 |
| anonymous | doc-a | GET | 401 |
| A | doc-b/download | GET | 403 |
Как работает авторизованный запуск
Сначала диагностируется вход. Затем проверяется собственный объект и только после этого чужой. В учебном API пользователь A читает свой заказ, но не заказ B и не отдельный маршрут его счёта. Истёкший токен или отсутствующий fixture делает проверку неполной: отказ без работающего положительного контроля нельзя засчитать исправлением. Обновление токена должно сохранять нужную тестовую личность, а не незаметно переключать её на администратора.
python3 access-fixture.py
# В другом терминале: до исправления — 200 с чужим объектом
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
# После — 403; doc-a остаётся доступен пользователю a
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"Первичные источники: OWASP: REST Security
Продолжить: Безопасность JWT: как проверить токены и отзыв доступа в своём API
Что можно и нельзя вывести из OpenAPI
Импорт OpenAPI 3 описывает доступные операции и параметры. Он не сообщает, какой документ принадлежит B и может ли гость его читать. Разрешите нужные операции чтения и добавьте тестовые данные отдельно. Внешние ссылки спецификации не являются разрешением загружать произвольные ресурсы; используйте поддерживаемый самодостаточный формат. Импорт Postman и общий анализ GraphQL этим руководством не обещаются.
Production и staging
Для production согласуйте ограниченный профиль отдельно. Проверки изменения полей и активных входов проводите на staging с подготовленными записями и планом очистки. Ответ 403 после PATCH не доказывает, что запись не успела измениться: приложение могло сохранить данные до ошибки. Сравните состояние через разрешённую контрольную операцию. Не используйте реальные заказы, платежи или клиентские документы как расходный материал теста.
Первичные источники: OWASP: REST Security
Продолжить: Как добавить проверки безопасности в CI/CD и GitHub Actions
Как читать покрытие и лимиты
Бюджет запросов и времени общий для запуска и его компонентов. Количество импортированных операций не равно количеству полностью исследованных сценариев. Уточняйте, что реально выполнено и почему остальное пропущено: истёкшая сессия, неподходящее окружение, ограничение цели или исчерпанный бюджет. Конкретные квоты берутся из каталога. Не повышайте скорость запросов, чтобы скрыть проблему покрытия за красивым числом проверок.
Как исправить и повторить
Для исправления сохраните минимальный запрос, нарушенное правило, версию сборки и маскированное доказательство. Повторите исходный сценарий после выкладки и проверьте, что владелец всё ещё работает с объектом. Затем закрепите проверку в расписании или CI. Автоматизация делает сценарий повторяемым, но не исследует все новые ветви бизнес-логики без обновления матрицы.
Продолжить: Проверка своего сайта на уязвимости по URL
Воспроизводимые примеры и материалы
Учебные данные — синтетические. Файлы не содержат действующих ключей или клиентской базы. Запускайте примеры только в собственной изолированной тестовой среде.
Протокол проверки примера: версии, действия и наблюдения
Вопросы и ответы
Нужны ли два аккаунта?
Для части наблюдений достаточно одного. Межпользовательская изоляция требует независимых личностей и известных объектов с заданными правами.
Можно дать только токен?
Токен может подходить для входа, но не задаёт владельцев объектов и ожидаемые разрешения. Эти данные нужно описать отдельно.
Нужен ли исходный код?
Для поддерживаемых проверок работающего HTTP API — нет. Это не означает статический анализ репозитория.
Можно проверять mobile backend?
Да, если подключён поддерживаемый HTTP API. Бинарный анализ мобильного приложения не входит в эту проверку.
Будут ли изменяться данные?
Активные сценарии могут изменять тестовые данные, поэтому требуют staging, согласия и подготовки. Профиль нужно выбирать осознанно.
Чем это отличается от ручного пентеста?
Scantelio повторяет поддерживаемые сценарии с заданными входами. Ручное исследование может изучать новую бизнес-логику и цепочки, не описанные в этих сценариях.
Автор и источники
Редакция Scantelio: методика и границы проверки. Проверка примера: 2026-11-02.
Перенесите проверку на свой проект
Подготовить проверку APIВыберите свой проект после входа. Ничего не сканируется без подтверждения и согласия.