В API право проверяют для GET, но изменение доступно через PATCH. Как подтвердить обход авторизации?
Нужно выполнить одну и ту же операцию изменения от пользователя без требуемого права, используя PATCH вместо разрешённого или проверяемого метода, и подтвердить успешное изменение чужого либо административного ресурса. Если сервер принимает операцию без независимой проверки полномочий, это обход авторизации на уровне маршрута или HTTP-метода.
Важно проверять не только код ответа, но и фактическое состояние ресурса после запроса. Без изменения данных результат может быть ложноположительным, например из-за формального ответа сервера или фоновой обработки.
HTTP-методы изначально описывали намерение операции: GET предназначен для получения данных, PATCH — для частичного изменения ресурса. На практике приложения часто реализуют обработчики методов раздельно, поэтому наличие проверки доступа в одном маршруте не означает её автоматического применения к другим.
Подход с проверкой авторизации на каждом серверном действии появился как ответ на риск доверия к клиентскому интерфейсу. Скрытие кнопки или запрет вызова GET не защищают ресурс, если другой маршрут позволяет выполнить критическую операцию.
Предположим, пользователь имеет право просматривать ресурс, но не может его изменять. GET может корректно возвращать данные, тогда как обработчик PATCH проверяет только аутентификацию, наличие полей или принадлежность к общей группе пользователей.
Последствие — изменение чужих данных, повышение привилегий или обход бизнес-ограничений. Особенно опасна ситуация, когда разные методы проходят через разные контроллеры, шлюзы или middleware, а разработчик считает проверку в одном из них общей для всего ресурса.
Сначала нужно определить тестовый ресурс и две учётные записи: владельца или администратора и пользователя без права изменения. От имени второй учётной записи следует отправить PATCH к ресурсу, доступному для чтения, изменив безопасное тестовое поле.
Затем нужно проверить несколько вариантов, которые реально поддерживает контракт API: идентификатор чужого ресурса, собственный ресурс с запрещённым действием, отсутствие ожидаемого поля роли или разрешения. Нельзя считать обходом ответ только с кодом 2xx: следует повторно запросить ресурс и убедиться, что значение действительно изменилось.
Контрольный тест выполняется от пользователя с законным правом. Он показывает, что операция в принципе работает, а отрицательный тест — что отказ зависит от полномочий, а не от формата данных. Ожидаемый безопасный результат для неразрешённого действия — отказ авторизации, обычно 403 Forbidden; 401 Unauthorized уместен, когда отсутствует или недействительна аутентификация.
Проверка должна учитывать маршрутизацию: PATCH может быть отдельным endpoint, вложенным ресурсом или альтернативным способом изменения через POST. Поэтому вывод формулируют для конкретной операции, а не для метода вообще. Исправление должно обеспечивать серверную проверку права непосредственно перед изменением ресурса, независимо от метода, интерфейса и видимости элемента в клиенте.
Централизация middleware уменьшает риск пропуска проверки, но не заменяет проверку предметного права: общий фильтр может подтвердить только вход в систему, тогда как решение о допустимости изменения конкретного объекта должно учитывать его владельца, состояние и роль пользователя.
В системе управления проектами обычный участник может просматривать проект. Интерфейс не показывает ему форму изменения настроек, а GET-маршрут защищён проверкой членства в проекте. При проверке PATCH выяснилось, что middleware требовал только действующую сессию, поэтому участник мог изменить признак публичности проекта.
Рассматривались три варианта. Проверять запрет только в веб-интерфейсе было быстро, но не защищало API. Добавить отдельную проверку только в PATCH устраняло найденный маршрут, однако оставляло риск в других операциях. Выбранным решением стала общая серверная политика для права изменения проекта с применением её ко всем операциям записи и отдельными тестами на каждый маршрут.
После исправления участник получил отказ, состояние проекта не изменилось, а владелец сохранил возможность выполнять операцию. Дополнительно проверили альтернативный POST-маршрут и массовое изменение, поскольку одинаковое бизнес-действие не должно получать разные права из-за способа вызова.
Нет. Нужно проверить отсутствие побочного эффекта: перечитать ресурс, проверить аудит и связанные сущности. Возможен ответ 403 после частичного изменения или, наоборот, ответ 200 без применения операции; поэтому доказательством служит сопоставление состояния до и после запроса.
Нет. Основная гипотеза относится к обходу проверки при альтернативном способе записи, а не к названию метода. Следует проверить все поддерживаемые операции, меняющие тот же ресурс, включая POST, PUT, массовые действия и вложенные маршруты, но не смешивать их результаты: для каждого маршрута нужен отдельный ожидаемый результат.
При отсутствии аутентификации сервер допускает действие без установления личности пользователя. Здесь личность обычно установлена, но сервер неверно оценивает её полномочия для конкретного ресурса или операции. Это дефект авторизации, и его можно обнаружить только сравнением действий пользователей с разными правами, а не одной проверкой доступа анонимного клиента.