Уязвимости входа по паролю
Для веб‑сайтов, использующих процесс входа по паролю, пользователи либо самостоятельно регистрируют учётную запись, либо получают её от администратора. Такая учётная запись связана с уникальным именем пользователя и секретным паролем, который пользователь вводит в форме входа для аутентификации.
В этой модели факт знания секретного пароля считается достаточным доказательством личности пользователя. Это означает, что безопасность веб‑сайта компрометируется, если злоумышленник сможет получить или угадать учётные данные другого пользователя. Этого можно добиться разными способами. В следующих разделах показано, как злоумышленник может использовать атаки перебора, а также некоторые из изъянов в защите от перебора. Вы также узнаете об уязвимостях базовой HTTP‑аутентификации.
Атаки перебором (brute force)
Атака перебором — это когда злоумышленник использует метод проб и ошибок, чтобы угадать действительные учётные данные. Эти атаки обычно автоматизируются с помощью словарей (wordlists) имён пользователей и паролей. Автоматизация процесса, особенно с использованием специализированных инструментов, потенциально позволяет злоумышленнику совершать огромное число попыток входа на высокой скорости.
Перебор — это не всегда просто полностью случайные догадки имён и паролей. Используя базовую логику или общедоступные знания, злоумышленники могут «подстроить» атаки перебора, делая гораздо более обоснованные предположения. Это значительно повышает эффективность таких атак. Веб‑сайты, полагающиеся на вход по паролю как на единственный метод аутентификации, могут быть крайне уязвимы, если не реализуют достаточной защиты от перебора.
Перебор имён пользователей
Имена пользователей особенно легко угадать, если они следуют узнаваемому шаблону, например адресу электронной почты. Например, очень часто бизнес‑логины имеют формат firstname.lastname@somecompany.com. Однако даже при отсутствии очевидного шаблона иногда даже учётные записи с высокими привилегиями создаются с использованием предсказуемых имён, таких как admin или administrator.
Во время аудита проверьте, не раскрывает ли веб‑сайт потенциальные имена пользователей публично. Например, можете ли вы получить доступ к профилям пользователей без входа? Даже если фактическое содержимое профилей скрыто, имя, используемое в профиле, иногда совпадает с именем для входа. Также проверьте HTTP‑ответы на предмет раскрытия адресов электронной почты. Встречаются случаи, когда ответы содержат адреса электронной почты пользователей с высокими привилегиями, таких как администраторы или ИТ‑поддержка.
Перебор паролей
Пароли аналогично можно перебирать, при этом сложность зависит от надёжности пароля. Многие сайты принимают форму политики паролей, вынуждающей пользователей создавать пароли высокой энтропии, которые, по крайней мере теоретически, сложнее взломать перебором. Обычно это включает принудительное соблюдение паролей с:
Минимальным количеством символов
Смесью строчных и заглавных букв
Хотя бы одним специальным символом
Однако, хотя пароли высокой энтропии трудно взломать компьютерам, мы можем использовать базовые знания о человеческом поведении, чтобы эксплуатировать уязвимости, которые пользователи невольно привносят в систему. Вместо создания сильного пароля со случайной комбинацией символов пользователи часто берут запоминающийся пароль и пытаются «впихнуть» его в рамки политики. Например, если mypassword не допускается, пользователи могут попробовать Mypassword1! или Myp4$$w0rd.
В случаях, когда политика требует регулярной смены паролей, пользователи также часто вносят незначительные, предсказуемые изменения в предпочитаемый пароль. Например, Mypassword1! превращается в Mypassword1? или Mypassword2!.
Знание вероятных учётных данных и предсказуемых шаблонов означает, что атаки перебором часто могут быть гораздо более изощрёнными — и, следовательно, эффективными, — чем простое перебирание всех возможных комбинаций символов.
Перечисление имён пользователей (username enumeration)
Перечисление имён пользователей — это когда злоумышленник по наблюдаемым изменениям поведения сайта может определить, действителен ли данный логин. Перечисление имён обычно происходит либо на странице входа (например, когда вы вводите правильное имя пользователя, но неправильный пароль), либо на формах регистрации, когда вы вводите уже занятое имя. Это значительно сокращает время и усилия, необходимые для перебора логина, поскольку злоумышленник быстро формирует короткий список действительных имён пользователей.
При попытке перебора страницы входа обращайте особое внимание на любые различия в:
Статус‑кодах: Во время атаки перебором возвращаемый HTTP‑статус‑код, скорее всего, будет одинаковым для подавляющего большинства попыток, поскольку большинство из них окажутся неверными. Если догадка вернёт иной статус‑код, это сильный признак того, что имя пользователя было правильным. Наилучшей практикой является всегда возвращать один и тот же статус‑код независимо от результата, но этой практике следуют не всегда.
Сообщениях об ошибке: Иногда возвращаемое сообщение об ошибке отличается в зависимости от того, неверны ли и имя пользователя, и пароль, или только пароль. Наилучшая практика — использовать идентичные, обобщённые сообщения в обоих случаях, но мелкие опечатки иногда проскакивают. Достаточно одного символа не на месте, чтобы сообщения отличались, даже если этот символ не виден на отрисованной странице.
Времени ответа: Если большинство запросов обрабатывалось за сопоставимое время, любые отклонения могут указывать, что «за кулисами» происходило что‑то иное. Это ещё один признак того, что угаданное имя пользователя может быть корректным. Например, сайт может проверять правильность пароля только если имя пользователя действительно. Этот дополнительный шаг может слегка увеличить время ответа. Пусть это и тонко, но злоумышленник может сделать задержку более заметной, введя чрезмерно длинный пароль, обработка которого займёт ощутимо больше времени.
Слабая защита от перебора
С высокой вероятностью атака перебором будет включать множество неудачных попыток до успешного компрометационного входа. Логически защита от перебора строится на том, чтобы максимально затруднить автоматизацию процесса и снизить скорость, с которой злоумышленник может пытаться входить. Два наиболее распространённых способа предотвращения атак перебором:
Блокировка учётной записи, к которой пытается получить доступ удалённый пользователь, при слишком большом числе неудачных попыток входа
Блокировка IP‑адреса удалённого пользователя при слишком частых попытках входа подряд
Оба подхода обеспечивают разную степень защиты, но ни один не неуязвим, особенно если реализован с ошибками в логике.
Например, вы можете столкнуться с тем, что ваш IP блокируется при слишком большом количестве неудачных попыток входа. В некоторых реализациях счётчик неудачных попыток сбрасывается, если владелец IP успешно входит. Это означает, что злоумышленнику достаточно периодически входить в собственную учётную запись, чтобы не допустить достижения лимита.
В этом случае достаточно просто вставить свои собственные учётные данные через определённые интервалы в словарь, и такая защита становится практически бесполезной.
Блокировка учётной записи
Один из способов, которым сайты пытаются предотвратить перебор, — блокировать учётную запись при выполнении определённых подозрительных критериев, обычно при заданном числе неудачных попыток входа. Как и обычные ошибки входа, ответы сервера, указывающие на блокировку учётной записи, также могут помочь злоумышленнику перечислять имена пользователей.
Блокировка учётной записи обеспечивает определённую защиту от целевого перебора конкретной учётной записи. Однако этот подход недостаточно защищает от атак перебором, при которых злоумышленник пытается получить доступ к любому случайному аккаунту.
Например, следующий метод позволяет обойти такую защиту:
Сформируйте список кандидатов имён пользователей, которые, вероятно, действительны. Это можно сделать через перечисление имён пользователей или просто на основе списка распространённых имён.
Выберите очень короткий список паролей, которые, по вашему мнению, хотя бы один пользователь, скорее всего, использует. Важно, чтобы число выбранных паролей не превышало допустимое число попыток входа. Например, если вы выяснили, что лимит — 3 попытки, нужно выбрать не более 3 догадок пароля.
С помощью инструмента вроде Burp Intruder попробуйте каждый из выбранных паролей с каждым из кандидатов имён пользователей. Таким образом вы сможете попытаться перебрать каждый аккаунт, не инициируя блокировку. Вам нужен лишь один пользователь, использующий один из трёх паролей, чтобы скомпрометировать учётную запись.
Блокировка учётной записи также не защищает от атак credential stuffing. Это использование огромного словаря пар username:password, составленного из подлинных учётных данных, украденных при утечках. Credential stuffing опирается на то, что многие люди переиспользуют одни и те же имя и пароль на нескольких сайтах, и, следовательно, есть шанс, что некоторые компрометированные учётные данные из словаря также действительны на целевом сайте. Блокировка учётной записи не защищает от credential stuffing, потому что для каждого имени пользователя выполняется всего одна попытка. Credential stuffing особенно опасен тем, что иногда позволяет злоумышленнику скомпрометировать множество разных аккаунтов одной автоматизированной атакой.
Лимитирование скорости по пользователю (user rate limiting)
Другой способ, которым сайты пытаются предотвратить атаки перебором, — лимитирование скорости по пользователю. В этом случае слишком большое число запросов на вход за короткое время приводит к блокировке вашего IP‑адреса. Обычно IP может быть разблокирован одним из следующих способов:
Автоматически по истечении определённого времени
Вручную администратором
Вручную пользователем после успешного прохождения CAPTCHA
Лимитирование скорости иногда предпочитают блокировке учётной записи, поскольку оно меньше подвержено перечислению имён пользователей и атакам отказа в обслуживании. Тем не менее, это всё ещё не полностью безопасно. Как мы видели на примере одной из лабораторных работ ранее, существует несколько способов, которыми злоумышленник может манипулировать своим видимым IP, чтобы обойти блокировку.
Поскольку лимит основан на скорости HTTP‑запросов, отправляемых с IP‑адреса пользователя, иногда также возможно обойти эту защиту, если удаётся угадать несколько паролей одним запросом.
Базовая HTTP‑аутентификация
Хотя она достаточно старая, относительная простота и лёгкость внедрения означают, что вы иногда можете встретить базовую HTTP‑аутентификацию. При базовой HTTP‑аутентификации клиент получает от сервера токен аутентификации, сформированный конкатенацией имени пользователя и пароля и кодированием результата в Base64. Этот токен хранится и управляется браузером, который автоматически добавляет его в заголовок Authorization каждого последующего запроса следующим образом:
По ряду причин это в целом не считается безопасным методом аутентификации. Во‑первых, он предполагает многократную отправку учётных данных пользователя с каждым запросом. Если сайт также не внедряет HSTS, учётные данные могут быть перехвачены в атаке «человек посередине».
Кроме того, реализации базовой HTTP‑аутентификации часто не поддерживают защиту от перебора. Поскольку токен состоит исключительно из статических значений, он может быть уязвим к перебору.
Базовая HTTP‑аутентификация также особенно уязвима к атакам, связанным с сессиями, особенно к CSRF, от которых сама по себе она не защищает.
В некоторых случаях эксплуатация уязвимой базовой HTTP‑аутентификации может дать злоумышленнику доступ лишь к на вид неинтересной странице. Однако помимо предоставления дополнительной поверхности атаки, учётные данные, раскрытые таким образом, могут переиспользоваться в других, более конфиденциальных контекстах.
Last updated