Как токен авторизации влияет на баги с правами доступа
Что проверяют
Понимаете ли вы, что токен отвечает на вопрос «кто вы», а права проверяет сервер, и что большая часть багов доступа живёт в разрыве между этими двумя вещами. Следом обычно просят описать, как вы проверите, что пользователь не видит чужие данные.
Как отвечать
Сначала коротко про устройство. Токены бывают непрозрачные (случайная строка, сервер ищет её в хранилище) и самодостаточные, чаще всего JWT. JWT подписан, но не зашифрован: payload читается простым декодированием Base64URL, роли в нём видны. Подпись защищает от подделки, только если сервер её действительно проверяет.
Типичные баги и как их ловить:
- устаревшие права в токене: роль сняли, а JWT с ролью администратора живёт до истечения
exp. Проверка: сменить роль и повторить запрос старым токеном; - проверка на клиенте вместо сервера: кнопка скрыта, но прямой запрос к API проходит. Проверяется через Postman или curl в обход интерфейса;
- IDOR (BOLA): токен валиден, но сервер не сверяет владельца ресурса. Пользователь A подставляет в
/orders/123номер заказа пользователя B; - вертикальные права: обычный пользователь вызывает админские эндпоинты;
- подпись и алгоритм: сервер принимает токен с
alg: none, с изменённым payload или подписанный чужим ключом; - жизненный цикл: после выхода или смены пароля токен и refresh token продолжают работать, refresh можно использовать повторно;
- коды ответа: без токена или с истёкшим ожидается 401, с валидным без прав 403. Путаница ломает клиент, который по 401 должен обновить токен, а не выкидывать пользователя.
Удобный приём: матрица «роль × эндпоинт × действие» и набор токенов на каждую роль, который прогоняют автотестами. В Burp Suite для такой проверки есть расширения вроде Autorize.
Где спотыкаются
Говорят, что JWT шифруется и поэтому безопасен. Стандартный JWT только подписан, класть в него секреты нельзя.
Проверяют права только через интерфейс. Скрытая кнопка не означает запрета на сервере.
Тестируют с одним тестовым аккаунтом. Для багов доступа нужны минимум два пользователя одной роли и по одному пользователю каждой другой роли.