Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о изучении ролей пользователей.
- Тестирование: введение и задачи
- Сбор информации с помощью поисковых систем
- Определение веб-сервера
- Поиск информации в метафайлах веб-сервера
- Определение веб-приложений на сервере
- Поиск утечек информации в комментариях и метаданных
- Определение точек входа веб-приложения
- Составление карты веб-приложения
- Определение фреймворка веб-приложения
- Определение веб-приложения
- Составление карты архитектуры веб-приложения
- Тестирование конфигурации инфраструктуры веб-приложения
- Изучение расширений файлов
- Поиск страрых версий веб-приложения, скрытых файлов и резервных копий
- Поиск административных интерфейсов
- Тестирование HTTP методов
- Тестирование HSTS
- Тестирование кросс-доменной политики
Резюме
Общепринято в современных корпоративных системах определять роли пользователей. В большинстве реализаций подобных систем предполагается существование как минимум двух ролей: администратор и обычный пользователь. У администратора есть доступ к привилегированной информации и функционалу, в то время как у пользователя подобного доступа нет, у него обеспечивается только доступ к обычному бизнес-функционалу и информации. Роли должны разрабатываться исходя из функционала, предоставляемого веб-приложением.
Важно помнить что не всегда правильно усложнять авторизацию. В более доверенных окружениях, где конфиденциальность не является критичной, можно обойтись более мягкими мерами, ограничившись контролем рабочего процесса веб-приложения и логгированием действий пользователей, не создавая сложную структуру ролей, которыми тяжело управлять. Необходимо придерживаться принципа Золотой середины — определять только необходимые роли, не давая чрезмерно больших полномочий пользователям, но и не урезая чрезмерно их права.
Задачи тестирования
Нужно изучить все роли, определенные веб-приложением, рассмотреть какие права они предоставляют.
Как тестировать
С помощью администраторов и разработчиков веб-приложения, или же без таковой, создать матрицу разрешений и запретов для всех ролей. В данной матрице должны быть рассмотрены все роли, предоставляемые веб-приложением. В том случае если подобная матрица уже существует, пентестеру необходимо убедиться в том что она соответствует действительности.
Пример 1.
Роль | ПраваОбъект | Ограничения |
Администратор | ЧтениеДанные клиентов | |
Менеджер | ЧтениеДанные клиентов | Только записи относящиеся к его отделу |
Персонал | ЧтениеДанные клиентов | Только данные выбранные менеджером |
Клиент | ЧтениеДанные клиентов | Только собственные данные |
Реальный пример матрицы можно увидеть в документации по WordPress[1], в которой определяются 6 ролей от супер администратора до подписчика.
Пример 2.
Войти в веб-приложение с правами администратора и посетить страницы, доступные только администраторам. Затем войти с правами пользователя и попытаться посетить те же страницы.
Инструменты
Наиболее тщательное и полное изучение возможно только вручную, но автоматизированные пауки также являются полезными. Необходимо для каждой роли запускать паука (не забывайте исключать ссылки на выход из веб-приложения из контекста паука).
Справочные материалы
- Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007
- Role engineering and RBAC standards
Санация
Решение различных проблем может быть следующим:
- детальная разработка ролей
- ранжирование ролей
- разделение обязанностей