IDOR, контроль доступа и SSRF

Самые недооценённые уязвимости — не «магические» инъекции, а ошибки в проверке прав. Разберём IDOR и SSRF.

IDOR: ссылка не равна праву

IDOR (Insecure Direct Object Reference) возникает, когда доступ к объекту определяется только идентификатором в запросе, без проверки прав. Если по адресу /orders/123 вы видите свой заказ, а сменив число на /orders/124 — чужой, это IDOR.

Корень — сервер доверяет, что пользователь запросит только «свои» id. Но id легко поменять. Это часть более широкой категории OWASP Broken Access Control (сломанный контроль доступа) — лидера последних рейтингов.

Защита

• Всегда проверяйте на сервере: принадлежит ли объект текущему пользователю.
• Не полагайтесь на «скрытость» id или на проверки только в интерфейсе.
• Применяйте проверку прав централизованно, а не в каждом обработчике вручную.

orders = {123: {"owner": "alice"}, 124: {"owner": "bob"}}

def get_order(order_id, current_user):
    order = orders.get(order_id)
    # Ключевая строка: проверяем владельца, а не только наличие
    if not order or order["owner"] != current_user:
        return "403 Доступ запрещён"
    return order

print(get_order(123, "alice"))   # свой заказ — ок
print(get_order(124, "alice"))   # чужой — запрет

SSRF: сервер делает запрос за вас

SSRF (Server-Side Request Forgery) — когда приложение по просьбе пользователя ходит на указанный им адрес (например, «загрузи картинку по URL»). Если не ограничить адреса, злоумышленник может заставить сервер обратиться к внутренним системам, недоступным извне.

Защита

• Allow-list разрешённых доменов вместо запрета «плохих».
• Блокировка обращений к внутренним адресам (localhost, приватные диапазоны, метаданные облака).
• Отдельный сетевой сегмент и минимальные права для сервиса, делающего внешние запросы.

Общий вывод раздела: большинство серьёзных дыр — это не экзотика, а отсутствие проверки «а можно ли». Контроль доступа на сервере — фундамент безопасности.