Аудит AuthZ с помощью ИИ: анализ границ разрешений в Ory Kratos

ИИ плохо находит баги, но отлично порождает подозрения.

В сфере безопасности самое дешевое, что может сделать ИИ, — это создать поток ложных отчетов. Именно поэтому программы bug bounty приостанавливают работу или ужесточают правила.

Я использую ИИ иначе. Я позволяю ИИ генерировать избыточное количество гипотез на основе моего каталога «запахов» AuthZ (AuthZ Smell Catalog). Затем я приступаю к основной работе. Моя задача — опровергнуть эти гипотезы.

Успешный аудит — это не список багов. Это таблица опровергнутых идей, не прошедших проверку.

Я провел аудит исходного кода Ory Kratos. Kratos отвечает за управление идентификацией и пользователями. Это зона высокого риска, так как система использует множество идентификаторов и публичных API.

Я проверил пять гипотез:

  • H1: В коде отсутствует авторизация для Admin API.
  • H2: Утечки данных между разными идентификаторами или тенантами (cross-tenant).
  • H3: Повторное использование токенов в сценариях восстановления.
  • H4: Подмена личности (identity confusion) в сценариях настройки.
  • H5: Назначение тенанта через тело запроса (request payload).

Результаты:

  • H1: ОПРОВЕРГНУТА. Авторизация реализована на сетевом уровне, а не в обработчике кода. Это заложено архитектурой.
  • H2: ОПРОВЕРГНУТА. Центральный слой доступа к данным фильтрует все запросы по tenant ID. Пользователи не могут это обойти.
  • H3: ОПРОВЕРГНУТА. Токены одноразовые и имеют ограниченный срок действия.
  • H4: ОПРОВЕРГНУТА. Сценарии привязаны к сессии, а не к вводу пользователя.
  • H5: ОПРОВЕРГНУТА. Tenant ID берется из системного контекста, а не из тела запроса.

Было выдвинуто пять гипотез. Результат — ноль находок. Это и есть успешный аудит.

Два урока для вашей работы в сфере безопасности:

  1. Безопасность на уровне развертывания может выглядеть как отсутствие защиты. Если «страж» находится на сетевом уровне, код будет казаться беззащитным. Не сообщайте об этом, пока не проверите архитектуру.

  2. Найдите «узкое место» (chokepoint). Если система обеспечивает границы на уровне данных, отдельным обработчикам не нужны проверки. Вместо вопроса «проверяет ли этот обработчик права доступа», спрашивайте: «может ли кто-нибудь получить доступ к данным в обход этого узкого места?».

Используйте ИИ, чтобы отсеивать кандидатов. Используйте людей, чтобы проверять выживших. Ценность заключается в отсеве.

Источник: https://dev.to/fdjedkdlsspec/ai-assisted-authz-review-reading-permission-boundaries-in-ory-kratos-31cg

Дополнительное сообщество для обучения: https://t.me/GyaanSetuAi