🛡 Защищаем свои ресурсы. Часть 7: Контроль доступа и получение прав Всем привет 👋 Продолжаем образовательную рубрику про уязвимости, которые чаще всего приводят к реальным инцидентам.
Сегодня разберём контроль доступа и то, как из обычного пользователя внезапно получается администратор.
Если коротко: Broken Access Control - это когда система должна запрещать, но почему-то разрешает.
Без взлома. Без вирусов. Просто потому, что логика контроля доступа реализована криво.
Что такое контроль доступа
Контроль доступа - это правила, которые определяют:
• кто может видеть данные • кто может менять настройки • кто может выполнять опасные действия • какие роли что могут делать
Проблема начинается там, где:
➡️ правила есть ➡️ роли есть ➡️ а проверки работают не везде
Вертикальная эскалация привилегий
Самый опасный сценарий - вертикальная эскалация.
Это когда обычный пользователь получает доступ к функциям администратора.
Например:
• пользователь без прав открывает админ-панель • удаляет аккаунты • меняет настройки • получает доступ к данным других клиентов
С точки зрения бизнеса - катастрофа.
Как это выглядит на практике
Частый класс ошибок — расхождение в обработке URL.
Сервер может по-разному трактовать:
• регистр символов • слэш в конце • «расширения» у URL • дополнительные сегменты
В результате:
/ADMIN/DELETEUSER /admin/deleteUser.any /admin/deleteUser/
могут вести к одному и тому же эндпоинту, но проверки срабатывают не всегда.
Типичные сценарии из лабораторий На практике это выглядит так:
• robots.txt честно подсказывает путь к админке • в JS-файле в комментарии лежит URL панели управления • в cookie флаг isAdmin=false, который можно поменять • в JSON-запросе достаточно добавить roleId=2 • id=my меняется на id=carlos и данные открываются
Никакой магии. Просто сервер доверяет тому, что прислал клиент.
IDOR - самый частый грех
Insecure Direct Object Reference - классика.
Когда приложение напрямую использует переданные ID:
• пользователей • файлов • заказов • документов
и не проверяет, имеет ли пользователь право их видеть.
Иногда это выглядит ещё хуже:
• пользователя редиректит на login • но данные всё равно улетают в redirect-запросе • или в логах • или в ответе API
Почему это особенно опасно
Broken Access Control:
• не вызывает ошибок • не ломает сайт • не выглядит подозрительно
С точки зрения системы - всё работает корректно.
Поэтому такие уязвимости:
❌ живут годами ❌ находят после утечек ❌ приводят к штрафам и репутационным потерям
Почему так происходит
Самые частые причины:
• проверки только на первом шаге • доверие Referer или заголовкам • логика доступа размазана по фронту и бэку • «ну сюда же никто не зайдёт» • отсутствие негативных сценариев тестирования
Классическая фраза: «Мы же проверили доступ на основной странице» Как от этого защищаются Контроль доступа нельзя «прикрутить потом».
Работает только системный подход:
• проверка прав на каждом запросе • серверные проверки, а не фронтовые • единый механизм авторизации • тестирование IDOR и эскалаций • принцип минимальных привилегий
Хороший вопрос для команды:
«А что будет, если пользователь изменит этот параметр?»
Вывод
Broken Access Control - это не про хакеров. Это про ошибки в мышлении и архитектуре.
Система может быть:
• с HTTPS • без XSS • без SQL-инъекций
И при этом позволять обычному пользователю делать то, что должен делать только администратор.
Продолжение следует 👉 Загрузка файлов
