Контроль доступа и бизнес-логика

Зачем это нужно

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

Теория

Контроль доступа должен проверяться на сервере при каждом обращении к объекту, а не только при отображении интерфейса. Классические ошибки: вертикальное повышение прав (пользователь получает доступ к административным функциям), горизонтальное (доступ к данным другого пользователя того же уровня), небезопасные прямые ссылки на объекты, отсутствие проверки прав для вложенных ресурсов, доверие к идентификатору, пришедшему от клиента, и кэширование ответов без учёта прав.

Бизнес-логика: последовательность операций, проверки лимитов, скидок, статусов, повторная обработка запросов, обход проверок через частичное выполнение или гонки. Такие дефекты проявляются в деньгах и в репутации. Их ищут моделированием сценариев: что должен делать пользователь, что он может сделать технически, где проверки дублируются, а где отсутствуют.

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

Ключевые концепции

Вертикальное и горизонтальное повышение прав

Доступ к более привилегированным функциям и к данным других пользователей того же уровня.

Небезопасная прямая ссылка на объект

Использование пользовательского идентификатора без проверки владельца.

Единая точка решения о доступе

Централизованная проверка прав, чтобы не полагаться на память разработчика.

Опасная гонка

Состояние между проверкой и действием, позволяющее обойти ограничение.

Идемпотентный ключ

Уникальный идентификатор операции для защиты от повторного выполнения.

Аудит решений о доступе

Запись того, кто получил доступ к чему и на каком основании.

Инструменты

• Ручное тестирование нескольких учётных записей с разными ролями в учебном приложении.
• Burp Suite Community и его возможности сравнения запросов разных пользователей.
• OWASP WSTG — разделы по контролю доступа и бизнес-логике.
• Автотесты на права доступа в коде приложения.
• Средства моделирования сценариев: диаграммы потоков и таблицы прав.

Практика в легальных лабораториях

• В учебном приложении создайте трёх пользователей с разными ролями и составьте таблицу: кто что должен видеть.
• Проверьте, доступны ли объекты чужого пользователя при прямом обращении по идентификатору.
• Опишите один сценарий бизнес-логики и найдите в нём допущение, которое можно обойти.
• Напишите автотест на отсутствие доступа для пользователя с меньшими правами.
• Составьте рекомендации: как централизовать проверку доступа в приложении.

Защита, детект и защитные меры

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

Правовая рамка и этика

• Проверка с несколькими учётными записями допустима только в своей лаборатории или по согласованию с владельцем системы.
• Не выгружайте и не сохраняйте реальные данные других пользователей даже как доказательство.

Типичные ошибки

• Считать, что скрытая кнопка в интерфейсе — это защита.
• Проверять права только на уровне маршрутов и забыть про объекты.
• Игнорировать бизнес-логику, концентрируясь на технических дефектах.

Чек-лист «умею»

• Различаю вертикальное и горизонтальное повышение прав.
• Умею спланировать проверку доступа с несколькими ролями.
• Нахожу допущения в бизнес-сценариях.
• Проектирую централизованную проверку прав.
• Умею написать автотест на доступ.

Вопросы на интервью

• Как вы проверяете, что контроль доступа реализован корректно?
• Какие дефекты бизнес-логики вы знаете?
• Почему скрытие элементов интерфейса не является защитой?

Источники и первоисточники

• OWASP — памятка по контролю доступа
• WSTG — контроль доступа и бизнес-логика