Базовые уязвимости в методах авторизации
Сегодня решил структурно разобрать, какие существуют способы аутентификации и какие уязвимости могут встречаться при их реализации.
Здесь не будет подробного разбора какого-то одного метода. Я постараюсь обобщённо покрыть большую часть распространённых механизмов, объяснить принцип их работы и показать основные точки риска.
Для начала небольшое уточнение: • аутентификация отвечает на вопрос: «Кто ты?»; • авторизация отвечает на вопрос: «Что тебе разрешено?».
На практике эти механизмы связаны и поэтому ошибки в аутентификации приводят к обходу авторизации.
━━━━━━━━━━ 1. Basic Authentication ━━━━━━━━━━
Один из самых простых и старых способов аутентификации.
Клиент передаёт логин и пароль внутри HTTP-заголовка: Authorization: Basic base64(login)
Base64 — это НЕ шифрование, а обычное кодирование. Полученную строку можно без ключа вернуть в исходный вид.
Если соединение не защищено TLS, логин и пароль могут быть перехвачены практически в открытом виде.
Сегодня Basic Auth чаще всего можно встретить лишь в легаси.
━━━━━━━━━━ 2. Session Authentication ━━━━━━━━━━
Классическая схема для большинства веб-приложений.
После успешного входа сервер создаёт сессию, сохраняет её на своей стороне и передаёт браузеру идентификатор сессии через cookie. При следующих запросах браузер автоматически отправляет эту cookie серверу, а сервер по её значению определяет пользователя.
Типичные проблемы: • хранение роли или уровня доступа непосредственно в cookie без криптографической защиты или слабой защиты; • предсказуемый или слишком короткий идентификатор сессии; • Cookie Poisoning — изменение значений cookie для влияния на серверную логику; • CSRF — браузер автоматически прикладывает cookie к поддельному запросу с сайта атакующего; • отсутствие флагов HttpOnly, Secure и SameSite; • отсутствие завершения сессии после выхода или смены пароля.
━━━━━━━━━━ 3. JWT Authentication ━━━━━━━━━━
Один из моих любимых механизмов, потому что при его реализации существует множество мест, где можно ошибиться и получить уязвимость)
JWT — это формат токена, а не самостоятельный протокол авторизации.
Основные формы JWT: • JWS — подписанный токен, целостность которого подтверждается цифровой подписью; • JWE — зашифрованный токен, содержимое которого скрыто от клиента.
JWT обычно содержит идентификатор пользователя, роли и дополнительные claims — утверждения о пользователе или самом токене. Например: • sub — идентификатор пользователя; • exp — время окончания действия токена; • iss — тот, кто выпустил токен; • aud — сервис, для которого предназначен токен.
Типичные проблемы: • отсутствие проверки подписи; • принятие алгоритма none; • возможность подменить алгоритм подписи; • слабый или короткий секрет при использовании HMAC;
Более подробно про формат jwt и его уязы я осветил в отдельном посте: ➥ https://setka.ru/posts/019cb398-77ec-7b81-a722-0e47191534ad
━━━━━━━━━━ 4. OAuth 2.0 ━━━━━━━━━━
Сам по себе OAuth 2.0 — это не механизм аутентификации, а протокол делегирования доступа. Он позволяет одному приложению получить ограниченный доступ к данным пользователя в другом сервисе без передачи его логина и пароля. Например, приложение может запросить доступ к профилю пользователя или его репозиториям в GitHub. За вход пользователя обычно отвечает не чистый OAuth 2.0, а OpenID Connect, построенный поверх него.
Уязвимостей здесь дофига, большая часть зависит от того, кто и как настраивал интеграцию. Основные проблемы: • недостаточно строгая проверка redirect_uri; • повторное использование authorization code;
redirect_uri — это адрес, на который сервер авторизации возвращает пользователя после входа. Если проверка этого адреса реализована некорректно, authorization code или токен может быть отправлен на подконтрольный атакующему сайт.
━━━━━━━━━━ 5. OpenID Connect (OIDC) ━━━━━━━━━━
OpenID Connect — это надстройка над OAuth 2.0, которая добавляет полноценную аутентификацию пользователя. Часто используется для реализации SSO
Основные проблемы: • доверие неподписанным данным; • отсутствие проверки подписи
