Оглавление
Атаки по времени
Атаки по времени — это класс вредоносных атак на продукт, при которых длительность времени, которое требуется вашему приложению для выполнения задачи, приводит к утечке некоторой информации. Возьмем, к примеру, приложение, которое принимает для проверки электронную почту и пароль. Если нет пользователя с указанным адресом электронной почты, оно возвращает ошибку за 5 мс, но если указан действительный адрес электронной почты пользователя с неправильным паролем, оно возвращает ошибку за 500 мс.
Для злоумышленника разница во времени между этими двумя запросами может сделать относительно очевидным, есть ли действительное электронное письмо или нет. Если разница была более тонкой, злоумышленник может сделать много запросов в течение длительного времени и усреднить их, чтобы отличить разные случаи.
Является ли это большой проблемой?
Может показаться, что это не так уж важно, но, допустим, я пытаюсь найти чей-то личный e-mail. У меня есть только его имя, и я знаю, что он подписался на ваш сайт. Я могу перебрать множество вариантов firstname.lastname@gmail.com или lastname{3digitnumber}@gmail.com и так далее, пока не найду их реальный адрес электронной почты.
Как мы можем это исправить?
Чтобы решить эту проблему, нам нужно убедиться, что все пути кода занимают одинаковое количество времени. Это означает, что мы должны избегать раннего возврата в чувствительных частях кодовой базы. В случае, когда мы проверяем электронную почту и пароль пользователя, вместо того, чтобы возвращаться раньше времени, если электронная почта не найдена, мы должны проверить пароль на соответствие жестко заданному значению, а затем вернуть false.
Так, в примере с проверкой электронной почты типичный поток будет выглядеть следующим образом:
- Существует ли пользователь с таким адресом электронной почты? (1 мс)
- Если да, то каков хэш его пароля? (1 мс)
- Совпадает ли хэш пароля с предоставленным паролем? (400 мс)
Этот поток хорошо работает, когда предоставлены правильные email и пароль, но он становится уязвимым для атаки по времени в следующем сценарии:
- Существует ли пользователь с таким адресом электронной почты? (1 мс)
- Если нет, возврат (1 мс)
Один из способов избежать этой уязвимости, как я уже упоминал выше, заключается в том, чтобы заставить и правильные, и неправильные потоки следовать одним и тем же процедурам для более тесного согласования по времени:
- Существует ли пользователь с таким адресом электронной почты (1 мс)
- Если нет, сравнить предоставленный пароль с хэшем пароля (400 мс)
- Возврат false в любом случае (1 мс)
Это гарантирует, что функция занимает одинаковое количество времени для всех входов, что затрудняет злоумышленнику извлечение информации.
Хотя вы должны делать все возможное для защиты от временных атак, вы также можете добавить дополнительные средства защиты для обеспечения безопасности. Поскольку тонкие временные атаки основаны на выполнении большого количества запросов, еще одним средством защиты здесь является ограничение скорости. Ограничив количество запросов, мы можем сделать невозможным для злоумышленника различать разные случаи.
При создании потоков аутентификации в приложениях можно легко упустить из виду такие тонкие уязвимости, как временные атаки в коде. Хотя может показаться странным намеренное замедление работы кода, предотвращение потенциальной утечки личной информации стоит того.