В статье я хочу наглядно показать, как использовать abuse-тестирование (проверку на возможность злоупотреблений или недокументированного использования) софта, и примеры того, к чему это может привести. Это не четкая инструкция, как нужно делать, а скорее, пища для идей, которые потом уже будут реализованы на конкретном проекте.
Немного о проекте
Проект, на котором мне довелось использовать этот вид тестирования, из авиационной сферы. Его цель — онлайн-экзаменация сотрудников, которые участвуют в грузовых авиаперевозках. Проект состоит из двух частей-приложений:
- Админская часть: конструктор экзамена. Приложение, с помощью которого сотрудник на стороне заказчика может создавать курсы и экзамены для прохождения студентом: конфигурировать наполнение, добавлять 3D-объекты, задавать верные ответы и т.д.
- Студенческая часть: прохождение экзамена. Приложение, с помощью которого студент видит доступные курсы/экзамены, может их пройти, получить результаты и детальный фидбек.
Abuse-тестирование, конечно же, приходится только на студенческую часть, так как только у студента будет желание получить более высокие результаты на экзамене и как-то «считерить» при прохождении курса.
С чего начать?
Я раньше не имел дела с таким видом тестирования, поэтому решил сначала определить наиболее критичные для подобного вида атак области. И уже потом применять к ним различные техники. Забегу вперед — кажется, идея оказалась хорошей.
Я выделил такие блоки приложения:
- Доступ к экзамену по роли/юзеру. Экзаменов много, как и преподавателей и студентов. Каждый конкретный экзамен должен быть доступен ТОЛЬКО конкретному студенту, которому он предназначался.
- Доступность экзамена для сдачи. У курса и экзаменов есть дата, после которой они перестают быть доступными для сдачи.
- Таймер. При входе в любой экзамен стартует таймер, за время которого студент может экзамен проходить. По истечении таймера экзамен и курс завершаются автоматически.
- Переходы между секциями. Студент должен проходить экзамен последовательно, переход из одной секции в другую (в рамках одного экзамена) завершает предыдущую, и изменить ответы в завершенной части уже нельзя.
- Завершение экзамена. Когда экзамен закончился, студент перенаправляется на страницу курса, результаты экзамена автоматически сохраняются, и пройти курс повторно нельзя.
- Действия с завершенным курсом и результатами. Студенту по факту завершения курса доступен только просмотр результатов курса и экзаменов в нем. У админа по ID курса также есть возможность получить его результаты.
Разберем каждую часть по отдельности
Доступ к экзамену по роли/юзеру
Ожидание: приложение корректно реагирует на попытку доступа к НЕ своему экзамену. Нет возможности просмотреть какие-либо детали, повлиять на тот или иной процесс чужого экзамена.
Как тестировать: тестирование в этом случае разбивается на две части. В первом случае мы проверяем валидацию на бэкенде, во втором — поведение на интерфейсе. Так как все действия совершаются через API, добавляем все API из пользовательского пути студента в любой REST-клиент и указываем во всех header «чужой» токен студента.
По той же логике проверяем доступ к экзамену из-под роли админа.
Тестирование на интерфейсе, по сути, заключается только в верификации ошибок, которые возникают при переходе по URL чужого экзамена или курса. Этот вид тестирования менее приоритетен, так как нам важнее убедиться, что у нас есть валидация на бэкенде, чем то, что увидит потенциальный читер.
Итоговое решение на проекте: реализована бэкенд-валидация, которая предотвращала любые действия под чужим токеном. В случае с контролем доступа это наиболее верное решение.
Доступность экзамена для сдачи
Ожидание: приложение скрывает кнопку входа в курс. Отсутствует возможность входа/редактирования/сдачи экзамена.
Как тестировать: здесь есть сразу несколько подходов, которые можно использовать для обхода этого бизнес-правила.
- Корректировка свойств кнопки в DOM страницы, установка значения Enabled и т.д.
- Правка локального времени на машине. Если у нас есть конкретная дата, с которой доступен курс, то установка локальной даты на более ранний момент может позволить войти в него.
- Переход по прямому URL. Имея другие курсы/экзамены, которые все еще доступны, можно понять закономерность формирования URL. В большинстве случаев при входе в адресную строку добавляется name или ID, указание которых в URL даст возможность получить к нему доступ.
- Прохождение экзамена на момент того, когда он станет недоступным.
Итоговое решение на проекте: по любому экзамену хранится серверное время в базе, а также реализована бэкенд-валидация, которая предотвращает любые действия с экзаменом, если они происходят после заданного срока.
По согласованию с заказчиком — возможность с помощью читинга войти в «просроченный» экзамен и просмотреть некоторые его свойства. Верификация подобного решения проводится путем тестирования API по экзамену с истекшим сроком.
Интересный факт: дату и время доступности устанавливает админ, в своем часовом поясе. А шесть часов вечера у админа не равно шести часам вечера у студента в другой части земного шара. Так что надо обратить внимание, чтобы указанные дата и время хранились в UTC формате, а затем корректно переводились в часовую зону клиента.
В следующей части расскажу о тестировании остальных блоков приложения — и поделюсь своими выводами о том, зачем вообще нужно abuse-тестирование.
Этот материал – не редакционный, это – личное мнение его автора. Редакция может не разделять это мнение.
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: