Предположив, что сервер предпринимает действия на основе определенного условия, рассмотрим ситуацию, в которой сервер выполняет вычисления в зависимости от результата этого условия и затем передает ответ пользователю. В обоих случаях, то есть как при выполнении вычислений, так и при их отсутствии, сервер возвращает ответ пользователю. Стоит отметить, что в ситуации, когда сервер выполняет вычисления, он расходует определенное количество ресурсов, что приводит к увеличению времени ответа сервера. Обычно такие различия во времени ответа настолько малы, что не заметны конечному пользователю. Тем не менее, выявление этих тонких различий во времени ответа может привести к непреднамеренной утечке данных.
Теперь рассмотрим практический пример этой ситуации, который основан на процессе входа в приложение. Предположим, что указанный логин правильный, но пароль неверный: в таком случае сервер может принять решение выполнить вычисления, например верификацию пароля. Если сервер выполняет эти вычисления, это может потребовать дополнительных ресурсов и привести к более долгому времени ответа по сравнению с ситуацией, когда вычисления не выполняются. Хотя различия во времени ответа обычно малы, они присутствуют и могут быть измерены злоумышленником.
Тот же процесс, но когда также логин неверный:
В случае таких тонких различий во времени ответа злоумышленник может попытаться использовать эту информацию, чтобы сделать вывод о правильности логина. Например, злоумышленник может провести атаку типа timing attack, анализируя время, которое сервер затрачивает на ответ на запросы с различными логинами. Сравнивая времена ответов, злоумышленник может выявить, какой запрос занял больше времени, что указывает на правильный логин. Выявление логина пользователя позволяет злоумышленнику провести атаку методом перебора паролей. В некоторых случаях это также может привести к утечке конфиденциальной информации, особенно когда логином является электронная почта, связанная с конкретным человеком, а тестируемое приложение представляет собой портал с контроверсионным контентом.
Тестирование с помощью Burp Suite — Request Timer
При поиске уязвимостей такого рода полезным будет плагин для Burp под названием Request Timer. Этот плагин позволит нам исследовать время ответа сервера на заданные нами запросы.
Первым шагом будет перехват запроса, ответственного за вход пользователя, и его отправка в модуль Intruder:
Затем изменим пароль на длинную строку символов, чтобы увеличить нагрузку на сервер при генерации хеша пароля. Укажем место, где находится логин пользователя. В случае тестируемого приложения необходимо также добавить заголовок «X-Forwarded-For» и присвоить ему случайный IP-адрес, чтобы обойти блокировку многократных попыток входа с одного и того же IP-адреса. В связи с этим необходимо изменить тип атаки на «Pitchfork».
Добавим список логинов для проверки:
В плагине Request Timer задаем, чтобы он слушал модуль Intruder:
После запуска теста, на вкладке появятся сгенерированные запросы с временем ответа. Как можно заметить, для правильного логина время ответа значительно дольше. Таким образом, мы доказали, что приложение уязвимо для перебора логинов пользователей путем анализа времени ответа сервера.
Что делать?
Одним из решений данной проблемы является добавление функции, отвечающей за случайную задержку ответа сервера:
Тем не менее, проблема такого рода решений заключается в том, что мы все равно не имеем контроля над ситуациями, такими как замедление сети при попытке подключения к базе данных или различиями, возникающими при значительном росте базы данных.
Лучшим решением выглядит выполнение операций проверки правильности данных, предоставленных пользователем, асинхронно в фоновом режиме и немедленное уведомление пользователя о попытке входа. В таком случае вычисления и связанные с этим задержки останутся незаметными для злоумышленника.
