Уязвимости входа по паролю
Для веб‑сайтов, использующих вход по паролю, пользователи либо самостоятельно регистрируют учётную запись, либо получают её от администратора. Такая учётная запись связана с уникальным именем пользователя и секретным паролем, который пользователь вводит в форме входа для аутентификации.
В этой модели факт знания секретного пароля считается достаточным доказательством личности пользователя. Это означает, что безопасность веб‑сайта компрометируется, если атакующий сможет получить или угадать учётные данные другого пользователя. Этого можно добиться разными способами. В следующих разделах показано, как атакующий может использовать атаки перебором, а также некоторые из изъянов в защите от перебора. Вы также узнаете об уязвимостях базовой HTTP‑аутентификации.
Атаки перебором
Атака перебором (brute-force) — это когда атакующий использует метод проб и ошибок, чтобы угадать действительные учётные данные. Эти атаки обычно автоматизируются с помощью словарей имён пользователей и паролей. Автоматизация процесса, особенно с использованием специальных инструментов, потенциально позволяет атакующему совершать огромное число попыток входа на высокой скорости.
Перебор — это не всегда просто полностью случайные имена и пароли. Используя базовую логику или общедоступные знания, атакующий может выполнять перебор, делая более обоснованные предположения. Это значительно повышает эффективность таких атак. Веб‑сайты, полагающиеся на вход по паролю как на единственный метод аутентификации, могут быть крайне уязвимы, если не реализуют достаточной защиты от перебора.
Перебор имён пользователей
Имена пользователей особенно легко угадать, если они следуют узнаваемому шаблону, например адресу электронной почты. Например, очень часто корпоративные учетные записи имеют формат 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 особенно опасен тем, что иногда позволяет атакующему скомпрометировать множество разных аккаунтов одной автоматизированной атакой.
Ограничение скорости пользователя
Другой способ, которым сайты пытаются предотвратить атаки перебором — лимитирование скорости пользователя. В этом случае слишком большое число запросов на вход за короткое время приводит к блокировке вашего IP‑адреса. Обычно IP может быть разблокирован одним из следующих способов:
Автоматически по истечении определённого времени
Вручную администратором
Вручную пользователем после успешного прохождения CAPTCHA
Ограничение скорости иногда предпочитают блокировке учётной записи, поскольку оно меньше подвержено перечислению имён пользователей и атакам отказа в обслуживании. Тем не менее, это всё ещё не полностью безопасно. Как было видно на примере одной из лабораторных работ ранее, существует несколько способов, которыми атакующий может манипулировать своим видимым IP, чтобы обойти блокировку.
Поскольку лимит основан на скорости HTTP‑запросов, отправляемых с IP‑адреса пользователя, иногда также возможно обойти эту защиту, если удаётся передать несколько паролей одним запросом.
Базовая HTTP‑аутентификация
Хотя она достаточно старая, относительная простота и лёгкость внедрения означают, что иногда можно встретить базовую HTTP‑аутентификацию. При базовой HTTP‑аутентификации клиент получает от сервера токен аутентификации, сформированный конкатенацией имени пользователя и пароля и кодированием результата в Base64. Этот токен хранится и управляется браузером, который автоматически добавляет его в заголовок Authorization каждого последующего запроса следующим образом:
По ряду причин это не считается безопасным методом аутентификации. Во‑первых, он предполагает многократную отправку учётных данных пользователя с каждым запросом. Если сайт также не внедряет HSTS, учётные данные могут быть перехвачены в атаке MITM.
Кроме того, реализации базовой HTTP‑аутентификации часто не поддерживают защиту от перебора. Поскольку токен состоит исключительно из статических значений, он может быть уязвим к перебору.
Базовая HTTP‑аутентификация также особенно уязвима к атакам, связанным с сессиями, особенно к CSRF, от которых сама по себе она не защищает.
В некоторых случаях эксплуатация уязвимой базовой HTTP‑аутентификации может дать атакующему доступ к неинтересной странице. Однако помимо предоставления дополнительной поверхности атаки, учётные данные, раскрытые таким образом, могут переиспользоваться в других, более конфиденциальных контекстах.
Last updated