Ролевая игра. Тестируем права доступа
Сайты, приложения, игры – информационные ресурсы, которые управляются пользователями. Чтобы разделить разрешенные и запрещенные для того или иного юзера действия, используются права доступа (ПД). Сфера применения ПД образует роли. Для примера, посмотрим на базовый сайт с возможностью регистрации.
На таком сайте «живут» 3 роли со своими правами и обязанностями:
1. Незарегистрированный пользователь
Все анонимы по умолчанию действуют в этой роли. Если мы наделим гостей сайта правом «Добавление комментариев», то зашедший на сайт пользователь сможет комментировать ваши интересности. А если нет, то для комментирования контента нужно будет сперва зарегистрироваться.
2. Авторизованный пользователь
Прошедшие аутентификацию и авторизацию анонимы получают новую роль. Только авторизованные пользователи могут управлять личным кабинетом, добавлять и редактировать личные данные, просматривать информацию о других персонажах. Незарегистрированные пользователи не имеют права на эти операции.
3. Администратор
Эта роль по умолчанию дает пользователю полный доступ к сайту. Администратор ресурса добавляет, удаляет блоки и дает или отнимает у других юзеров права на доступ к той или иной функциональности.
Как тестируем и на что обращаем внимание?
В первую очередь постараемся не удалить «Супер-админа», играясь с настройками.
- Создаем безопасного персонажа
Чтобы приблизиться к реальным активностям на проекте, хватит и дополнительного пользователя со схожими полномочиями админа. И уже этим персонажем мы тестируем ресурс и изменяем права доступа остальных пользователей.
- Проверяем в нескольких браузерах
Делаем одновременно: в одном изменяем ПД, в другом проверяем применение прав для юзера, таким образом разделяя пользовательские сессии.
- Проходим по прямой ссылке
Тестируем ограничения блоков, переходя на них по прямому URL адресу. Просмотр некоторых данных ресурса должен быть недоступен по ссылке для неавторизованного гостя сайта. Если доступ ограничен, то все ок: вместо закрытой информации анонимы получат предупреждающее сообщение в виде специальной страницы, чаще всего с кодом 403.
- Тестируем блокировку сущностей
Для ресурсов вроде сервисов продажи билетов и туров важно заблокировать элемент, когда к нему могут получить доступ сразу несколько пользователей. Есть два варианта блокировки:
+ Оптимистичная блокировка при сохранении проверяет БД на предмет более новой версии данных, оставленной другим юзером. Если она есть, то текущий пользователь заново загружает данный экземпляр сущности.
+ Пессимистичная блокировка сущностей используется, когда оптимистичная порождает слишком много коллизий. В этом случае только один юзер в текущий момент времени использует и меняет данный вариант сущности.
Можно тестировать с одного компьютера в нескольких браузерах или разными аккаунтами.
- Используем тестовую матрицу
Она упрощает работу тестера, наглядно показывает разрешенные и запрещенные действия, да и просто помогает ничего не упустить. Расписываем в ней все роли, пользователей, вариации ограничений возможностей наших персонажей.
А вот и простейший пример тестовой матрицы:
Контроль доступа является одной из основных проверок в рамках тестирования безопасности программного обеспечения. Даже проверка сайта местной библиотеки с тремя ролями грозит тестеру трудностями. А ведь популярные ресурсы с десятками ролей, тысячами пользователей и миллионами разрешений требуют целую армию администраторов! Нам сложно представить масштабы урона, если за тестирование возьмется дилетант. Привлекайте грамотных специалистов и не допускайте пробелов в безопасности ваших продуктов!