18.08.2016 @ 14:18 Перевод OWASP Testing Guide. Часть 2.9. owasp, web security Представляю вашему вниманию очередную часть перевода 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 Санация Решение различных проблем может быть следующим: детальная разработка ролей ранжирование ролей разделение обязанностей abychutkin 7485 Web security Читать дальше >>