Вопрос с собеседования · System design

Эндпоинт GET /orders/{id} проверяет, что пользователь аутентифицирован, и возвращает заказ по идентификатору. Что здесь не так?

MiddleБезопасность приложения
Ещё спрашивают так:
  • Что такое IDOR?
  • Почему нельзя проверять только аутентификацию?
Коротко

Проверено «кто ты» (аутентификация), но не «можно ли тебе этот заказ» (авторизация): любой вошедший пользователь читает чужие заказы, перебирая id. Это IDOR — Broken Access Control, A01 в OWASP Top 10.

  • Проверять владение на сервере в каждом запросе
  • Лучше — прямо в запросе: WHERE id = :id AND user_id = :current
  • UUID вместо чисел только затрудняет перебор, но не защищает: ссылки утекают

А ещё Запрет по умолчанию: новый эндпоинт закрыт, пока не описано правило доступа

Подробно

Уязвимость. GET /orders/1001 возвращает заказ, если пользователь вошёл. Пользователь меняет число на 1002 — и видит чужой заказ с адресом и телефоном. Это небезопасная прямая ссылка на объект (IDOR) — самый частый вид нарушения контроля доступа, первое место в OWASP Top 10.

Исправление:

  • проверка владения в каждом запросе на сервере — не в интерфейсе, не скрытием кнопки;
  • в выборке из базы: SELECT ... WHERE id = :id AND owner_id = :user — тогда чужая строка просто не найдётся, и забыть проверку сложнее, чем в отдельном if;
  • для сложных правил (роли, организации, общие документы) — централизованный слой авторизации (политики, ABAC, OPA), а не проверки, разбросанные по контроллерам;
  • ответ на чужой ресурс — обычно 404, а не 403: не подтверждать существование.

Чем не защититься: UUID вместо последовательных id уменьшает перебор, но ссылки попадают в логи, письма, историю браузера; проверка на клиенте; «секретность» URL.

Профилактика: запрет по умолчанию, тесты на доступ к чужим ресурсам для каждого эндпоинта, автоматические сканеры (два пользователя, перекрёстные запросы).

Что хотят услышать

  • Различие аутентификации и авторизации.
  • Название уязвимости и её место в OWASP.
  • Проверка владения на сервере, лучше в запросе к базе.
  • Почему UUID не решение; запрет по умолчанию.

Частые ошибки

  • Считать неугадываемые id защитой.
  • Проверять доступ только в интерфейсе.

Проверьте себя

Один верный вариант. Подумайте, потом откройте ответ.

Показать варианты и ответ
  • ✗Ничего: аутентификации достаточно, раз идентификаторы неугадываемые
  • ✗Проблема только в последовательных идентификаторах; переход на UUID полностью её решит
  • ✗Нужно перенести проверку прав на клиент, чтобы разгрузить сервер и упростить код
  • ✓Нет проверки владения: перебор id выдаст чужие заказы

Что спросят дальше

  • Чем 401 отличается от 403?
  • Почему запрет по умолчанию безопаснее перечисления запретов?

Разбор темы

Связанные вопросы

Партнёр платформы

Разбор собеседования с sotto

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

Разбор собеседования