Уязвимости в других механизмах аутентификации
В дополнение к базовой функциональности входа большинство веб‑сайтов предоставляет дополнительную функциональность, позволяющую пользователям управлять своей учётной записью. Например, пользователи обычно могут сменить пароль или сбросить его, если забыли. Эти механизмы также могут вносить уязвимости, которые злоумышленник способен эксплуатировать.
Обычно сайты уделяют внимание избежанию известных уязвимостей на своих страницах входа. Но легко упустить из виду, что необходимо предпринимать аналогичные меры, чтобы сопутствующая функциональность была столь же надёжной. Это особенно важно в случаях, когда злоумышленник может создать собственную учётную запись и, следовательно, имеет лёгкий доступ к изучению этих дополнительных страниц.
Сохранение состояния входа
Распространённая функция — оставаться в системе даже после закрытия сеанса браузера. Обычно это простая галочка с подписью вроде «Запомнить меня» или «Оставаться в системе».
Эта функциональность часто реализуется путём генерации некого «remember me»‑токена, который затем сохраняется в постоянном cookie. Поскольку владение этим cookie фактически позволяет обойти весь процесс входа, лучшей практикой является сделать этот cookie неподдающимся угадыванию. Однако некоторые сайты генерируют этот cookie на основе предсказуемой конкатенации статических значений, таких как имя пользователя и метка времени. Некоторые даже используют пароль как часть cookie. Этот подход особенно опасен, если злоумышленник может создать собственную учётную запись, потому что он может изучить свой cookie и потенциально вывести способ его генерации. Разобравшись в формуле, он может попытаться перебором подобрать cookie других пользователей, чтобы получить доступ к их аккаунтам.
Некоторые сайты исходят из предположения, что если cookie «зашифрован» каким‑то образом, его нельзя будет угадать, даже если он использует статические значения. Хотя это может быть верно при корректной реализации, наивное «шифрование» cookie с помощью простой двусторонней кодировки вроде Base64 не даёт никакой защиты. Даже использование корректного шифрования с однонаправленной хеш‑функцией не является абсолютно надёжным. Если злоумышленник легко определяет используемый алгоритм хеширования и соль не применяется, он потенциально может перебирать cookie, просто хешируя свои словари. Этот метод может использоваться для обхода лимитов попыток входа, если аналогичный лимит не применяется к попыткам угадывания cookie.
Даже если злоумышленник не может создать собственную учётную запись, он всё ещё может эксплуатировать эту уязвимость. Используя обычные техники, такие как XSS, злоумышленник может украсть «remember me»‑cookie другого пользователя и вывести из него способ конструирования cookie. Если сайт построен на открытом фреймворке, ключевые детали построения cookie могут быть даже задокументированы публично.
В некоторых редких случаях может оказаться возможным получить фактический пароль пользователя в открытом виде из cookie, даже если он захеширован. Захешированные версии известных списков паролей доступны онлайн, поэтому если пароль пользователя присутствует в одном из таких списков, «расшифровка» хеша порой сводится к вставке хеша в поисковую систему. Это демонстрирует важность использования соли в эффективном шифровании.
Сброс паролей пользователей
На практике некоторые пользователи забывают свой пароль, поэтому обычно есть способ его сбросить. Поскольку обычная аутентификация по паролю в этом сценарии невозможна, сайты должны полагаться на альтернативные методы, чтобы убедиться, что реальный пользователь сбрасывает собственный пароль. По этой причине функциональность сброса пароля по своей природе опасна и должна быть реализована безопасно.
Существует несколько распространённых способов реализации этой функции с различной степенью уязвимости.
Отправка паролей по электронной почте
Само собой разумеется, что отправка пользователям их текущего пароля никогда не должна быть возможной, если сайт изначально безопасно обращается с паролями. Вместо этого некоторые сайты генерируют новый пароль и отправляют его пользователю по электронной почте.
В целом пересылки постоянных паролей по небезопасным каналам следует избегать. В данном случае безопасность опирается на то, что сгенерированный пароль истечёт через очень короткий период или пользователь немедленно сменит пароль. В противном случае такой подход крайне уязвим для атак типа «человек посередине».
Электронная почта также в целом не считается безопасной, учитывая, что почтовые ящики и долговечны, и не предназначены для безопасного хранения конфиденциальной информации. Многие пользователи также автоматически синхронизируют почту между несколькими устройствами по небезопасным каналам.
Сброс паролей с использованием URL
Более надёжный метод сброса паролей — отправлять пользователям уникальный URL, ведущий на страницу сброса пароля. Менее безопасные реализации этого метода используют URL с легко угадываемым параметром для идентификации аккаунта, чей пароль сбрасывается, например:
В этом примере злоумышленник может изменить параметр user, указав любое известное ему имя пользователя. Затем он попадёт прямо на страницу, где потенциально можно установить новый пароль для произвольного пользователя.
Лучшей реализацией этого процесса является генерация высокоэнтропийного, трудноугадываемого токена и построение URL сброса на его основе. В идеале такой URL не должен давать никаких подсказок о том, чей пароль сбрасывается.
Когда пользователь посещает этот URL, система должна проверить, существует ли этот токен на сервере и, если да, пароль какого пользователя он должен сбросить. Этот токен должен истекать через короткий период и быть уничтожен немедленно после сброса пароля.
Однако некоторые сайты не проверяют токен повторно при отправке формы сброса. В этом случае злоумышленник может просто открыть форму сброса из своей учётной записи, удалить токен и использовать эту страницу для сброса пароля произвольного пользователя.
Если URL в письме для сброса генерируется динамически, он также может быть уязвим к отравлению ссылки сброса (password reset poisoning). В этом случае злоумышленник потенциально может украсть токен другого пользователя и использовать его, чтобы сменить пароль жертвы.
Смена паролей пользователей
Как правило, смена пароля включает ввод текущего пароля и затем нового пароля дважды. Эти страницы по сути опираются на тот же процесс проверки соответствия имени пользователя и текущего пароля, что и обычная страница входа. Следовательно, они могут быть уязвимы к тем же техникам.
Функциональность смены пароля может быть особенно опасной, если она позволяет злоумышленнику обращаться к ней напрямую без входа под пользователем‑жертвой. Например, если имя пользователя передаётся в скрытом поле, злоумышленник может отредактировать это значение в запросе, нацелившись на произвольных пользователей. Это потенциально может быть использовано для перечисления имён пользователей и перебора паролей.
Last updated