- Автор темы
- #1
Интересная статья про CSRF с переопределением HTTP метода, а также информация о некоторых особенностях сессионных cookie.
Во время моего путешествия по поиску ошибок я читал множество статей, чтобы узнать о различных методиках и подходах. Большинство статей, которые я читал, были написаны исследователями, которым удалось взломать Yahoo!. Именно из-за этого я решил взломать Yahoo! и не успокоился, пока не добился успеха. К счастью, мне удалось взломать их всего за 30 минут. Итак, без лишних слов, вот эта невероятная история.
Собрав все возможные домены и проверив, на каких из них работает веб-сервер, я сосредоточился на тех, которые не содержали слова Yahoo!. Почему-то мне казалось, что в этих поддоменах у меня больше шансов найти брешь в безопасности. Среди всех отфильтрованных доменов я решил выбрать один, который я назову vulnerable.com.
Лично я не люблю тратить свое время на ошибки с низким уровнем серьезности. Мне нравятся серьезные вызовы. Поэтому после продолжительного анализа рассматриваемого приложения я задумался о анализе функциональности для обновления данных учетной записи пользователя. Я хотел посмотреть, смогу ли я случайно найти CSRF (хотя в то время я не очень верил, что найду CSRF в таком очевидном месте, не говоря уже о такой компании, как Yahoo!).
Поэтому я использовал функционал сайта, чтобы изменить данные учетной записи пользователя, и изменил адрес электронной почты с [email protected] на [email protected].
Первоначальный запрос на изменение электронной почты выглядел следующим образом:
Поскольку мы пытаемся добиться CSRF, удобно проверить, принимает ли сервер запросы с произвольным происхождением. Некоторые серверы не позволяют инициировать запросы из произвольных источников. Однако сервер был дружелюбным и разрешал любому домену отправлять к нему HTTP-запросы:
В этот момент я собирался создать вредоносную HTTP-форму для использования CSRF. Однако я заметил, что запросы были сделаны с использованием метода HTTP PATCH.
Это проблема, поскольку HTTP формы принимают только ограниченный набор HTTP методов. Итак, первое, что пришло мне в голову, это изменить метод HTTP напрямую на POST. Однако это не сработало:
После этого я задумался о том, что еще я могу попробовать или как еще я могу вызвать неожиданное поведение на сервере. Поэтому мне пришла в голову идея изменить значение заголовка Content-type с application/json на application/x-www-form-urlencoded:
Увидев это, я решил преобразовать тело запроса из JSON в urlencoded, чтобы увидеть, присутствует ли ошибка в ответах сервера.
Я уже переписал тело запроса из JSON в urlencoded. Однако нам все еще нужно отправить этот запрос методом POST. Поскольку формы HTTP, как мы видели ранее, работают только с методами GET/POST.
Проблема здесь в том, что бэкэнд ожидает, что этот запрос прибудет с методом PATCH. После некоторых размышлений я придумал способ изменить HTTP метод до того, как он достигнет сервера. Для этого существует несколько способов, и каждый из них сильно зависит от языка программирования, используемого в серверной части.
Поэтому я использовал wappalyzer, чтобы посмотреть, какие технологии использует приложение. Благодаря нему я смог понять, что бэкенд приложения написан на Ruby On Rails. К счастью, этот фреймворк предлагает способ добиться переопределения метода HTTP, которого мы так хотим.
Наконец, со всеми этими ингредиентами вместе нам удалось обойти все ограничения, присутствующие в приложении, чтобы иметь возможность использовать CSRF, что позволит нам украсть произвольные учетные записи пользователей одним щелчком мыши:
После сообщения об уязвимости я понял, что эксплойт также может быть использован для изменения пароля пользователя. Это связано с тем, что приложение не запрашивало текущий пароль:
Поскольку мы можем изменить пароль и адрес электронной почты (способ восстановления пароля), нам удалось полностью получить учетную запись любого пользователя приложения всего одним щелчком мыши.
Я хотел оставить лучшее напоследок, я уверен, что многие из вас не знают об этом (хотя я не знаю, работает ли этот метод в Chrome сегодня).
Оказывается, Yahoo! не определил конкретный SameSite для сессионной cookie, используемой в запросах. Это не является серьезным риском для firefox, так как по умолчанию он использует LAX. Это предотвращает использование этой уязвимости в этом браузере. Судя по всему, разработчики Yahoo! думали, что все браузеры будут устанавливать эти файлы cookie в LAX и, следовательно, не должны будут использовать Anti-CSRF токен (поэтому необходимо иметь несколько уровней безопасности, лучше быть осторожным, чем слепо уверенным в чем-то).
Однако в Chrome все по-другому. Бывает, что Chrome из соображений совместимости временно разрешает файлам куки, которые явно не устанавливают атрибут SameSite, обрабатываться как None в течение двух минут. После этого браузер установит для них значение LAX . Chrome назвал эту функцию LAX+POST, и вы можете найти более подробную информацию о ней здесь. Есть несколько способов сделать эти две минуты, указанные Chrome, длиннее. Эти техники можно найти здесь.
Я не уверен, что этот трюк все еще работает в Chrome. Если это работает у вас в последней версии Chrome, дайте мне знать в поле для комментариев ;)
Как только я сообщил об этой уязвимости, она была принята в течение нескольких дней и вознаграждена через 3 месяца:
На этом пока все, надеюсь, вам понравилось и вы узнали столько же, сколько и я. Спасибо за чтение и удачного взлома!
- Telegram