Эксплуатация CSRF уязвимостей
Moody
Привет.
В этой статье я расскажу о 3-х интересных случаях в моей жизни, когда я повстречался с CSRF-уязвимостями.
Небольшое предисловие
CSRF (Сross Site Request Forgery — «межсайтовая подделка запроса») - атака, которая приводит к тому, что хакер может выполнить на незащищенном сайте массу различных действий от имени других, зарегистрированных посетителей.
Как это работает? После авторизации на сайте, у пользователя в браузере сохраняются токен сессии, который позволит ему в следующий раз не вводить заново данные для входа (если сессия не истечет), а также изменять какую - либо информацию в своем профиле, активничать на сайте и прочее. При последующих веб-запросах к сайту, токен сессии автоматически передается на сервер и позволяет приложению получить информацию о текущем пользователе для авторизации запроса. Если на сервере нет никаких проверок, например то, откуда отправлен запрос, злоумышленник сможет разместить на своем сайте hackeeeeer.com такую HTML-страничку, которая будет сабмитить HTML-форму на уязвимый сайт, при её открытии. Так как браузер автоматически вставляет куки пользователя в HTTP-запрос, то бэкенд просто не поймет, является ли данный запрос легитимным — результат ли это заполнения формы пользователем, или это CSRF-атака — и поменяет адрес доставки для пользователя на значение, которое выгодно для атакующего.
Критичность этой уязвимости сильно зависит от того, в каком месте на сайте она находится и какую операцию выполняет. Иногда она бывает почти безобидной и приводит к несущественным проблемам, например, таким, как несанкционированное изменение настроек профиля или опустошение корзины пользователя. А иногда злоумышленник может, буквально по щелчку пальцев, завладеть аккаунтом жертвы.
Приведу пару примеров.
Пример 1. Утечка информации о пользователях
Приложения часто отправляют или раскрывают информацию в соответствии с предпочтениями пользователя. Например, один из сервисов, который я тестировал, позволял детально настроить отправку уведомлений на Email. Меня заинтересовал пункт, который носил название "Ежемесячная отчетность о состоянии счета" (или что - то в этом духе). Он позволял получать письма, в которых, помимо информации об остатке на счете и транзакциях, также содержалась полная информация о профиле жертвы. В профиле пользователь мог указать своё ФИО, дату рождения, адрес проживания, номера телефонов, данные о кредитных картах и многое-многое другое. Запрос на включение таких уведомлений выглядел так:
POST /change_billing_email REQUEST BODY: email=NEW_EMAIL&csrftoken=12345
Уязвимость заключалась в том, что CSRF-токен здесь никак не валидировался (как и во всех примерах ниже) и в качестве его значения я мог указать любые данные. Запрос всё - равно бы выполнился успешно. И мне бы каждый месяц приходила бы информация о жертве (если бы она, конечно, предварительно перешла по "злой" ссылке).
Пример 2. Stored Self-XSS + CSRF
На одном финансовом сайте, который я находил, была возможность создавать ник для каждого из своих привязанных банковских счетов. Значение параметра, передававшего никнейм, было уязвимо для Self-XSS: не было никакой очистки "вредных" символов, проверки или экранирование вводимых пользовательских данных. Запрос на изменение никнейма выглядел так:
POST /change_account_nickname REQUEST BODY: nickname=<XSS ПЭЙЛОАД>&csrftoken=WRONG_TOKEN
Можно было прописать, помимо ника, JS код, который обязательно бы выполнился, когда жертва зашла бы в свой профиль.
Пример 3. Захват учеток при помощи CSRF
Это уже стало классикой, по крайней мере у меня. Не знаю, совпадение или нет, но на большинстве сайтов, которые я исследовал, присутствовала именно эта разновидность CSRF. Чаще всего её можно найти в функциях создания, изменения, сброса пароля от учетной записи.
POST /password_change REQUEST BODY: newpassword=XXX&newpassword=XXX
Это функция смены пароля. Думаю, комментарии излишни.
Узнали?