Оценка безопасности REST API: где проверять права и как принимать результаты

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

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

В этом главная идея полезной оценки безопасности REST API. Аутентификация отвечает на вопрос «кто обращается», авторизация — «что этот вызывающий может сделать с этим объектом, свойством и функцией в этом арендаторе прямо сейчас». Действительный токен или зеленая панель шлюза о втором ничего не говорят. Ниже показано, как строить охват вокруг этого различия, безопасно проверять идентичность, авторизацию, изоляцию арендаторов и бизнес-процессы, требовать пригодных доказательств и принимать решения заказчика.

Что включает оценка безопасности REST API

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

Реестр: API, версии, среды и машинные клиенты

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

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

Описание охвата и письменное разрешение

Обоснованное описание охвата согласуется до начала тестирования и называет как минимум следующее:

• Реестр API: конечные точки, версии и среды в охвате, включая порядок работы с недокументированными находками
• Модель идентичности: методы аутентификации, типы токенов, работа с сессиями, роли, арендаторы и машинные клиенты
• Классификация данных: какие ресурсы содержат персональные, финансовые или операционные данные
• Исключения и ограничения: исключенные сторонние сервисы, ограничения для продакшена, лимиты частоты запросов, окно тестирования и лица, которые могут остановить тест
• Запись о разрешении: кто одобрил тест, на какой срок и для каких целей

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

Идентичность, сессии и границы доверия токенов

REST API работают поверх HTTP — по описанию MDN, протокола прикладного уровня с клиент-серверной моделью, который применяется и для межмашинного взаимодействия, и для программного доступа к API. MDN называет HTTP протоколом без сохранения состояния: сам протокол не связывает запросы между собой. Это часто понимают неверно. Серверные сессии при этом возможны, и запрос не обязан нести полную идентичность вызывающего: непрерывность строится поверх протокола, а каждый запрос содержит что-то, по чему сервер узнает вызывающую сторону.

Cookie, токены и идентификаторы сессий

Распространены два способа. В первом сервер хранит состояние сессии и выдает клиенту идентификатор, обычно в cookie; по MDN, cookie добавляют состояние через заголовки Set-Cookie и Cookie. Идентификатор прав не содержит: это ссылка, которую сервер при каждом запросе сопоставляет с сохраненным состоянием. Во втором клиент предъявляет токен, часто в заголовке Authorization: непрозрачный токен проверяется по хранилищу сервера или провайдера идентификации, а самодостаточный несет подписанные утверждения — субъект, аудиторию, области доступа, срок действия, — которые API проверяет локально.

Ошибки у моделей разные. Идентификаторы сессий должны быть непредсказуемыми, жить разумное время и аннулироваться при выходе и смене привилегий. Для самодостаточных токенов важны подпись, допустимые алгоритмы и издатели, аудитория, срок действия, отзыв и сопоставление утверждений с правами; защите токенов и утверждений от подделки, кражи и злоупотребления посвящены материалы CISA Secure by Design. В обеих моделях учетные данные доказывают в лучшем случае, кто обращается, но не решают, к какому объекту, свойству или функции вызывающий получит доступ.

Где принимаются решения о доверии

Чтобы найти пробелы в авторизации, нанесите на карту все точки решений о доверии и выясните, что каждая из них проверяет на самом деле. Таблица — отправная точка; реальная карта строится по архитектуре системы.

Авторизация на уровне объектов, свойств и функций

OWASP API Security Top 10 2023 разделяет авторизацию на три отдельные категории: нарушение авторизации на уровне объектов, нарушение авторизации на уровне свойств объектов и нарушение авторизации на уровне функций. Этот список — документ для повышения осведомленности, и порядок пунктов не следует читать как рейтинг того, насколько часто каждая проблема встречается в конкретной инфраструктуре. Ценность списка для оценки — в словаре: это три разных вопроса, и для каждого нужны свои проверки.

Авторизация на уровне объектов

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

Авторизация на уровне свойств и массовое присвоение

Авторизация на уровне свойств отвечает на вопрос, может ли вызывающий читать или записывать конкретное поле. На выходе ответы раскрывают внутренние флаги, чужие контакты или цены другой роли, если сериализуется весь объект вместо отфильтрованного представления. На входе массовое присвоение (mass assignment) возникает, когда сервис привязывает все поля тела запроса к модели, и вызывающий может задать статус, роль, владельца или признак утверждения, которых интерфейс не предлагал. Оценка проверяет для каждой роли, какие свойства возвращаются и какие переданные принимаются, игнорируются или отклоняются. Устойчивое исправление — явные списки разрешенных свойств по ролям и операциям, а не черный список опасных полей.

Авторизация на уровне функций

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

Изоляция арендаторов в синхронных и асинхронных путях

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

Оценка изоляции арендаторов должна охватывать как минимум следующие пути:

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

Асинхронные пути проверять сложнее: результат появляется позже и в другом месте. Поэтому в охвате согласуют, как безопасно запускать задачи и наблюдать за ними, например в тестовом арендаторе с подготовленными данными. Охват мультиарендных систем шире разобран в руководстве по тестированию на проникновение для SaaS-компаний.

Бизнес-процессы и потребление ресурсов

В OWASP API Security Top 10 2023 неограниченное потребление ресурсов и неограниченный доступ к чувствительным бизнес-процессам выделены в отдельные категории. Они связаны, но не совпадают, и оценка должна рассматривать их раздельно.

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

Безопасная проверка требует предварительных договоренностей: показывать слабость лимита минимальным числом запросов, не исчерпывая ресурсы, и уточнить у владельца продукта, что считать злоупотреблением. Как задать охват такой работы, объясняется в статье об услугах тестирования безопасности бизнес-логики.

HTTP-поверхность за пределами списка конечных точек

Справочник MDN объясняет, что метод запроса указывает на его цель; чаще всего используются GET и POST. Для проверяющего важно, какие методы ресурс принимает на самом деле, а не какие задокументированы, и одинаково ли соблюдается авторизация во всех. Классический пробел — ресурс, защищенный от чтения, но принимающий недокументированный метод, изменяющий данные; он обнаруживается только при систематической проверке методов.

MDN делит коды состояния на пять классов, и то, как API их использует, многое показывает: непоследовательные ответы раскрывают существование ресурса, ошибки сервера — детали реализации. MDN также описывает Content-Type с MIME-типами и согласование содержимого через Accept, поэтому стоит проверить реакцию API на неожиданные типы содержимого и форматы.

CORS задаёт, каким источникам браузер разрешит читать ответы API. Он важен для браузерных клиентов, но не заменяет серверную авторизацию и не ограничивает произвольный небраузерный клиент. По MDN, условные запросы помогают избежать потери обновлений при одновременной записи, то есть важны для целостности данных. Переход на WebSocket и трафик через прокси явно включают в охват или исключают. Краткий чек-лист:

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

Методика и эталоны

Дисциплина планирования, выполнения и работы после тестирования

NIST SP 800-115 «Техническое руководство по тестированию и оценке информационной безопасности» вышла в сентябре 2008 года и заменила SP 800-42 2003 года. Ее цель — помочь организациям планировать и проводить технические тесты и проверки, анализировать результаты и разрабатывать стратегии устранения. Для проекта по API это дисциплина процесса: спланировать работу и правила взаимодействия, выполнить тесты в этих рамках, а после выполнения проанализировать результаты, превратить их в меры устранения и провести повторную проверку.

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

ASVS, WSTG, списки OWASP Top 10 и CWE

Такие проверки дает OWASP Web Security Testing Guide (WSTG): его области аутентификации, авторизации, управления сессиями и проверки входных данных напрямую применимы к REST. Указывайте версию WSTG: по замечанию OWASP, версионированный контент отражает состояние на определенный момент.

OWASP Application Security Verification Standard (ASVS) дает основу для тестирования технических мер безопасности и перечень требований к безопасной разработке, выравнивая охват и строгость проверок. Для заказчика он превращает расплывчатое обещание «протестировать API» в согласованный список проверяемых требований. Идентификаторы могут меняться между версиями, поэтому OWASP рекомендует ссылки с версией, например v5.0.0-1.2.5, а идентификатор без версии считает ссылкой на актуальную редакцию. Перечни публикуются в CSV, JSON и других форматах, так что результат удобно вести по каждому требованию и API: выполнено, не выполнено, неприменимо.

OWASP Top 10 для веб-приложений и OWASP API Security Top 10 — документы для повышения осведомленности: они хорошо объясняют приоритеты, но не заменяют план тестирования, и проверка только десяти пунктов оставит пробелы. MITRE CWE, включая CWE Top 25 Most Dangerous Software Weaknesses, дает словарь первопричин, оповещения CISA Secure by Design нацелены на устранение целых классов уязвимостей, а NIST Cybersecurity Framework 2.0 задает результаты управления рисками, в контексте которых читаются итоги оценки. Как сочетать эти источники, показано в статье об аудите безопасности приложений от охвата до решения.

Безопасные тестовые данные и ограничения продакшена

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

Какую бы среду ни выбрали, правила взаимодействия должны определять:

• Тестовые учетные записи для каждой роли и тестовые арендаторы с синтетическими данными, чтобы межарендные проверки не требовали чтения записей реальных клиентов
• Неразрушающие ограничения: какие операции записи, удаления и массовые операции разрешены и над какими объектами
• Лимиты частоты и временные окна, особенно для проверок ресурсов и бизнес-процессов
• Обращение со случайно увиденными реальными данными: минимальный просмотр, копирование только в объеме доказательств, оперативное уведомление
• Экстренную остановку: контактные лица с обеих сторон и условия паузы

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

Доказательства, повторная проверка и приемка

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

Матрица ниже показывает, как заказчик может определить критерии приемки до начала работ, чтобы слово «исправлено» значило для всех одно и то же.

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

Решения заказчика: охват и выбор подрядчика для оценки API

С понятными методикой и эталоном выбрать подрядчика проще. Руководство CISA Secure by Demand предназначено для переговоров о закупке, а совместное руководство ACSC при ASD и CISA о выборе безопасных технологий подчеркивает проверяемость. Принцип тот же: просите подрядчика показать, как он работает, а не просто описать.

1. Реестр и разрешениеПеречислить API, версии, среды и машинных клиентов, получить письменное одобрение, правила взаимодействия и условия остановки.
2. Границы доверияОтметить, где проверяются идентичность, токены, сессии и контекст арендатора и где сервисы полагаются на чужую проверку.
3. Матрица авторизацииСпланировать проверки объектов, свойств и функций по ролям и арендаторам, включая экспорт, задачи, кэши и косвенные ссылки.
4. Безопасное выполнениеТестировать на синтетических арендаторах в согласованных лимитах, сочетая автоматическую широту с ручной проверкой авторизации.
5. Доказательства и повторная проверкаПринимать находки по матрице доказательств, подтверждать исправления повтором и закреплять повторяющиеся причины регрессионными тестами.

Вопросы подрядчику

• Какая версия WSTG и какие требования ASVS определят охват и как будут устроены планирование, выполнение и отчет?
• Сколько учетных записей, ролей и арендаторов нужно для проверки авторизации объектов, свойств и функций?
• Как будет проверена изоляция арендаторов в экспорте, фоновых задачах, кэшах и косвенных ссылках, а не только в чтении?
• Можно ли увидеть обезличенный образец отчета, политику повторной проверки и правила работы в продакшене, включая случайный доступ к реальным данным и экстренную остановку?

Тревожные признаки

• Сырой вывод сканера, выданный за тест на проникновение
• Список OWASP Top 10 как единственный чек-лист
• Ссылки на стандарты без номеров версий
• Отсутствие обсуждения проверки авторизации для нескольких ролей и арендаторов
• Формулировки, представляющие оценку как сертификацию, аттестацию или гарантию безопасности
• Нежелание оформить письменное разрешение и охват до начала тестирования

Заявления о сертификатах, клиентах и результатах проверяйте самостоятельно. Доступность из интернета, чувствительные данные и мультиарендность оправдывают более глубокую ручную проверку авторизации и более широкий набор требований ASVS; внутренние малочувствительные API можно начинать с автоматизации и целевой ручной проверки аутентификации и авторизации. Фиксируйте глубину письменно до начала работ, чтобы сравнивать результаты между выпусками и подрядчиками. Для этого можно подготовить контур пентеста с Pentest.red и заранее согласовать системы, доступы, ограничения и ожидаемые доказательства.

Что должно остаться после оценки API

Оценка безопасности REST API полезна, когда она авторизована, спланирована, опирается на доказательства и не принимает успешный вход за корректный доступ. NIST SP 800-115 задает дисциплину процесса, WSTG — тестовые сценарии, ASVS — требования с версией, OWASP API Security Top 10 2023 — словарь для авторизации объектов, свойств и функций, потребления ресурсов и бизнес-процессов, CWE — язык первопричин. Вместе с реестром, картой границ доверия, проверками изоляции арендаторов в задачах, экспорте и кэшах и циклом повторной проверки они показывают глубину проверки, подтверждённые проблемы и результаты ретеста в проверенной версии API. Дальнейшие изменения требуют нового наблюдения и, при необходимости, повторной оценки.