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