Пользователь без административной роли видит скрытую в интерфейсе операцию. Как проверить, что сервер действительно запрещает её выполнение?
Нужно выполнить защищаемую операцию напрямую от имени пользователя без административной роли, минуя интерфейс, и убедиться, что сервер отклоняет запрос. Проверка считается успешной, если решение принимает сервер на основании серверной роли или разрешения, а данные не изменяются и побочных эффектов не возникает.
Ранние приложения часто полагались на ограничения интерфейса: скрывали кнопку, пункт меню или страницу для определённых пользователей. Такой подход решает только задачу отображения, но не контролирует сам запрос, поскольку клиентскую логику можно изменить или обойти.
Поэтому контроль доступа должен выполняться на сервере непосредственно перед защищаемой операцией. Это позволяет отделить удобство интерфейса от реального механизма авторизации.
Пользователь может увидеть административную операцию в сетевом трафике, документации или интерфейсном коде и повторить её вручную. Если сервер проверяет только факт входа в систему либо доверяет переданной роли, обычный пользователь получит возможность выполнить привилегированное действие.
Последствия зависят от операции: изменение настроек, просмотр чувствительных данных, управление пользователями, удаление объектов или получение административных полномочий. Даже ответ с ошибкой не всегда означает защиту: нужно проверить отсутствие изменения состояния, отправки уведомлений, создания фоновой задачи и других побочных эффектов.
Сначала нужно определить требуемое разрешение операции и создать тестовую учётную запись без него. Затем следует получить обычную пользовательскую сессию и воспроизвести административный запрос напрямую, изменяя только необходимые параметры. Не следует подменять роль в клиенте или полагаться на скрытие элемента интерфейса.
Ожидаемый результат — отказ на сервере, обычно с ответом, соответствующим политике приложения для запрета доступа. Важно различать отсутствие аутентификации и отсутствие полномочий: незалогиненный субъект обычно должен пройти проверку аутентификации, а вошедший пользователь без нужного разрешения — проверку авторизации.
Проверка должна охватывать каждый способ вызова операции: основной endpoint, альтернативный HTTP-метод, пакетную обработку, фоновые задания и связанные административные функции. Если разрешение зависит от контекста, например от организации или проекта, нужно проверить также попытку выполнить действие в чужом контексте.
Нельзя считать достаточным только анализ HTTP-статуса. Следует сравнить состояние системы до и после запроса, проверить аудит и связанные ресурсы. Отдельно нужно убедиться, что сервер не принимает роль, уровень привилегий или идентификатор разрешения из недоверенных данных клиента как источник истины.
Централизованная проверка полномочий обычно снижает риск расхождения правил между endpoints, но требует единообразной модели разрешений и корректного покрытия всех маршрутов. Слишком общий запрет проще поддерживать, однако он может нарушить легитимные сценарии; слишком детальная модель гибче, но сложнее для аудита и тестирования.
В системе управления проектами кнопка удаления проекта была скрыта для участника с ролью наблюдателя. Тестировщик обнаружил запрос удаления в журнале браузера и повторил его с сессией наблюдателя. Сервер вернул успешный ответ, а проект исчез — это подтвердило отсутствие серверной проверки полномочий.
Рассматривались три варианта исправления. Можно было оставить только скрытие кнопки, что дёшево, но не защищает endpoint; добавить проверку роли в каждом обработчике, что быстро исправляет проблему, но создаёт риск несогласованности; либо вынести проверку разрешения в общий слой и покрыть операции матрицей ролей, что требует больше работы, но улучшает единообразие.
Выбрали централизованную проверку с явным разрешением на удаление проекта и отдельной проверкой принадлежности проекта организации пользователя. После исправления запрос наблюдателя отклонялся, состояние проекта не менялось, а разрешённый запрос администратора продолжал работать.
Нет. Отказ должен быть проверен по фактическому состоянию системы и побочным эффектам. Endpoint может вернуть ошибку после частичного выполнения операции, поставить задачу в очередь или изменить связанные данные, поэтому нужны проверки до и после запроса, а для асинхронных действий — контроль конечного результата.
Роль — это групповой способ назначить набор прав, а разрешение описывает конкретную допустимую операцию. Проверка только названия роли может стать хрупкой при появлении новых ролей или исключений; проверка явного разрешения обычно точнее. При этом само разрешение должно вычисляться сервером из доверенной политики и контекста, а не приниматься из запроса клиента.
Одна бизнес-функция может иметь несколько входов: отдельный endpoint, пакетный вариант, экспорт, импорт или фоновую задачу. Если хотя бы один путь не применяет ту же проверку полномочий, пользователь может обойти защищённый основной маршрут. Поэтому тестировать нужно карту связанных операций и матрицу субъектов, ресурсов и разрешений, а не только видимый интерфейс.