Как тестировать софт на abuse: реальные примеры (часть I)

В статье я хочу наглядно показать, как использовать abuse-тестирование (проверку на возможность злоупотреблений или недокументированного использования) софта, и примеры того, к чему это может привести. Это не четкая инструкция, как нужно делать, а скорее, пища для идей, которые потом уже будут реализованы на конкретном проекте.

Немного о проекте

Проект, на котором мне довелось использовать этот вид тестирования, из авиационной сферы. Его цель — онлайн-экзаменация сотрудников, которые участвуют в грузовых авиаперевозках. Проект состоит из двух частей-приложений:

• Админская часть: конструктор экзамена. Приложение, с помощью которого сотрудник на стороне заказчика может создавать курсы и экзамены для прохождения студентом: конфигурировать наполнение, добавлять 3D-объекты, задавать верные ответы и т.д.
• Студенческая часть: прохождение экзамена. Приложение, с помощью которого студент видит доступные курсы/экзамены, может их пройти, получить результаты и детальный фидбек.

Abuse-тестирование, конечно же, приходится только на студенческую часть, так как только у студента будет желание получить более высокие результаты на экзамене и как-то «считерить» при прохождении курса. 

С чего начать?

Я раньше не имел дела с таким видом тестирования, поэтому решил сначала определить наиболее критичные для подобного вида атак области. И уже потом применять к ним различные техники. Забегу вперед — кажется, идея оказалась хорошей.

Я выделил такие блоки приложения:

• Доступ к экзамену по роли/юзеру. Экзаменов много, как и преподавателей и студентов. Каждый конкретный экзамен должен быть доступен ТОЛЬКО конкретному студенту, которому он предназначался.
• Доступность экзамена для сдачи. У курса и экзаменов есть дата, после которой они перестают быть доступными для сдачи.
• Таймер. При входе в любой экзамен стартует таймер, за время которого студент может экзамен проходить. По истечении таймера экзамен и курс завершаются автоматически.
• Переходы между секциями. Студент должен проходить экзамен последовательно, переход из одной секции в другую (в рамках одного экзамена) завершает предыдущую, и изменить ответы в завершенной части уже нельзя.
• Завершение экзамена. Когда экзамен закончился, студент перенаправляется на страницу курса, результаты экзамена автоматически сохраняются, и пройти курс повторно нельзя.
• Действия с завершенным курсом и результатами. Студенту по факту завершения курса доступен только просмотр результатов курса и экзаменов в нем. У админа по ID курса также есть возможность получить его результаты.

Разберем каждую часть по отдельности

Доступ к экзамену по роли/юзеру

Ожидание: приложение корректно реагирует на попытку доступа к НЕ своему экзамену. Нет возможности просмотреть какие-либо детали, повлиять на тот или иной процесс чужого экзамена.

Как тестировать: тестирование в этом случае разбивается на две части. В первом случае мы проверяем валидацию на бэкенде, во втором — поведение на интерфейсе. Так как все действия совершаются через API, добавляем все API из пользовательского пути студента в любой REST-клиент и указываем во всех header «чужой» токен студента. 

По той же логике проверяем доступ к экзамену из-под роли админа. 

Тестирование на интерфейсе, по сути, заключается только в верификации ошибок, которые возникают при переходе по URL чужого экзамена или курса. Этот вид тестирования менее приоритетен, так как нам важнее убедиться, что у нас есть валидация на бэкенде, чем то, что увидит потенциальный читер.

Итоговое решение на проекте: реализована бэкенд-валидация, которая предотвращала любые действия под чужим токеном. В случае с контролем доступа это наиболее верное решение.

Доступность экзамена для сдачи

Ожидание: приложение скрывает кнопку входа в курс. Отсутствует возможность входа/редактирования/сдачи экзамена.

Как тестировать: здесь есть сразу несколько подходов, которые можно использовать для обхода этого бизнес-правила.

1. Корректировка свойств кнопки в DOM страницы, установка значения Enabled и т.д.
2. Правка локального времени на машине. Если у нас есть конкретная дата, с которой доступен курс, то установка локальной даты на более ранний момент может позволить войти в него.
3. Переход по прямому URL. Имея другие курсы/экзамены, которые все еще доступны, можно понять закономерность формирования URL. В большинстве случаев при входе в адресную строку добавляется name или ID, указание которых в URL даст возможность получить к нему доступ.
4. Прохождение экзамена на момент того, когда он станет недоступным.

Итоговое решение на проекте: по любому экзамену хранится серверное время в базе, а также реализована бэкенд-валидация, которая предотвращает любые действия с экзаменом, если они происходят после заданного срока.

По согласованию с заказчиком — возможность с помощью читинга войти в «просроченный» экзамен и просмотреть некоторые его свойства. Верификация подобного решения проводится путем тестирования API по экзамену с истекшим сроком.

Интересный факт: дату и время доступности устанавливает админ, в своем часовом поясе. А шесть часов вечера у админа не равно шести часам вечера у студента в другой части земного шара. Так что надо обратить внимание, чтобы указанные дата и время хранились в UTC формате, а затем корректно переводились в часовую зону клиента.

В следующей части расскажу о тестировании остальных блоков приложения — и поделюсь своими выводами о том, зачем вообще нужно abuse-тестирование.