Cross-Site Request Forgery (CSRF)
Ранее мы обсуждали CORS, который касается Cross-Origin обмена данными и потенциальной возможности злоумышленников получить доступ к личным или конфиденциальным данным пользователя. Основное внимание там уделялось "чтению" данных.
Теперь давайте поговорим о другой подобной атаке, называемой CSRF, что расшифровывается как Cross-Site Request Forgery. Ключевое отличие здесь заключается в том, что CSRF сосредоточен на "выполнении действий".
Начнем с понимания того, что такое CSRF, через простой пример!
Внедрение CSRF с помощью функции удаления
Однажды я создал простую страницу блога. У него были функции создания, удаления и редактирования статей.
Существует множество способов реализации функции удаления, таких как вызов API или отправка формы. Однако я выбрал более простой подход, чтобы не утруждать себя.
Для простоты я подумал, что если сделаю эту функцию GET-запросом, я смогу просто использовать прямую ссылку для выполнения удаления, не используя много кода на фронтенде:
Удобно, правда? Затем на бэкенде я добавил некоторую валидацию, чтобы проверить, включает ли запрос идентификатор сессии и была ли статья написана автором этого идентификатора. Только если оба условия были выполнены, статья удалялась.
Кажется, я сделал все, что должен был: "Только автор может удалить свои собственные статьи." Это должно быть безопасно, верно? Неужели я что-то упустил?
Действительно, проверка разрешений была правильной: "Только автор может удалить свои собственные статьи." Но что, если кто-то другой удалит статью без ведома автора? Вы можете подумать, что я говорю ерунду. Как кто-то может удалить статью, если сам автор не инициировал это действие?
Ну, позвольте мне показать, как это можно сделать!
Предположим, что Боб — злодей, который хочет обмануть Петра, чтобы тот удалил свою собственную статью без его ведома. Как он может это сделать?
Зная, что Петр любит психологические тесты, Боб создает веб-сайт с психологическими тестами и отправляет его Петру. Однако на этом тестовом сайте есть кнопка, которая выглядит так:
Восторженный, Петр нажимает на кнопку "Start Test". При нажатии браузер отправляет GET-запрос на https://small-min.blog.com/delete?id=3 и, благодаря механизму браузера, также включает куки с small-min.blog.com.
Когда сервер получает запрос, он проверяет сессию и обнаруживает, что это действительно Петр и что статья была написана им. В результате сервер удаляет статью.
Это и есть CSRF - Cross-Site Request Forgery.
Вы явно находитесь на сайте психологических тестов, скажем, https://test.com, но вы неосознанно удалили статью с https://small-min.blog.com. Разве это не ужасно? Это действительно страшно!
Вот почему CSRF также известна как атака в один клик. Вы подвергаетесь компрометации всего лишь одним кликом.
Некоторые наблюдательные люди могут сказать: "Но разве Петр не понимает, что произошло? Он посетил блог, так что это не соответствует условию 'без его ведома'!"
Это незначительные проблемы. Что если мы изменим это так:
При открытии страницы мы тайно отправляем запрос на удаление с помощью невидимого изображения. На этот раз Петр действительно не имеет об этом никакого представления. Теперь это соответствует условию!
Из этого простого примера мы можем четко увидеть принципы и методы атаки CSRF.
Цель атаки CSRF заключается в том, чтобы "отправить запрос на целевой веб-сайт с другого веб-сайта, заставив целевой веб-сайт ошибочно полагать, что запрос был инициирован пользователем, когда это не так."
Достижение этого зависит от механизма браузера. Каждый раз, когда вы отправляете запрос на веб-сайт, он включает связанные куки. Если пользователь вошел в систему, запрос естественно включает его информацию (например, идентификатор сессии), что создает видимость, будто пользователь инициировал запрос.
В конце концов, сервер обычно не заботится о том, кто вы. Он просто распознает куки или, точнее, информацию, содержащуюся в куках. При отправке запроса с сайта A на сайт B он включает куки сайта B. Аналогично, при отправке запроса с сайта C на сайт B он также включает куки сайта B. Это ключевая причина, почему CSRF работает.
Однако в приведенном выше примере есть недостаток: "Почему бы не изменить запрос на удаление на POST?"
Совершенно верно! Давайте не будем лениться и правильно реализуем функцию удаления, используя POST. Таким образом, атака через <a> или <img> будет невозможна, верно? Если только... нет ли HTML-элемента, который может отправлять POST-запросы?
Есть один, он называется <form>.
После того как Петр нажал на него, он снова попал в ловушку, и статья была удалена. В прошлый раз это было через невидимое изображение, в этот раз — через форму.
Пример, приведенный в статье, выглядит следующим образом, мир веба действительно огромен и глубок:
Открываем невидимый iframe, чтобы результат после отправки формы появился внутри iframe, и эта форма также может быть автоматически отправлена, без каких-либо действий со стороны Петра.
На этом этапе вы понимаете, что изменение на POST бесполезно, CSRF все еще возможна.
Итак, вы придумываете умную идею: "Поскольку только формы могут отправлять POST-запросы на фронтенде, не могу ли я изменить свой API, чтобы принимать данные в формате JSON? Тогда формы больше не смогут использоваться!"
Для HTML-форм, enctype поддерживает только три типа:
application/x-www-form-urlencodedmultipart/form-datatext/plain
В большинстве случаев используется первый тип, второй тип применяется для загрузки файлов, а третий тип используется редко. Если вы хотите парсить JSON на стороне сервера, тип контента обычно application/json.
Таким образом, это утверждение наполовину верно. Для некоторых серверов, если тип контента запроса не application/json, будет выдана ошибка, и он не будет считаться допустимым запросом.
Неверная часть заключается в том, что для других серверов, пока содержимое тела в формате JSON, оно может быть принято, даже если тип контента text/plain. Тело в формате JSON можно построить с помощью формы ниже:
Эта <form> генерирует тело запроса в соответствии с правилом name=value, поэтому приведенная выше форма сгенерирует следующее тело запроса:
Мы использовали пример удаления статьи, который может показаться незначительным, но что если это банковский перевод? Злоумышленникам нужно всего лишь написать некоторый код на своей веб-странице, чтобы перевести деньги на свой счет, а затем распространить эту веб-страницу, чтобы получить чужие деньги.
После стольких разговоров давайте поговорим о том, как защититься от этого! Начнем с самой простой защиты — "пользователя".
Защита пользователя
Атаки CSRF работают, потому что пользователь уже вошел на атакуемую веб-страницу, что позволяет выполнять определенные действия. Хотя эти атаки должны обрабатываться веб-страницей, если вы действительно обеспокоены и волнуетесь, что веб-страница может не справиться с этим должным образом, вы можете выходить из системы после каждого использования сайта, чтобы избежать CSRF.
Однако то, что могут сделать пользователи, на самом деле очень ограничено. Реальная работа должна выполняться на стороне сервера.
Серверная защита
Причина, по которой CSRF опасен, заключается в "CS" в его названии: Cross-Site. Вы можете запустить атаку с любого сайта. Защита от CSRF может рассматриваться с этой точки зрения, простыми словами: "Как я могу заблокировать запросы из других источников?"
Подумайте об этом внимательно, в чем разница между запросом атаки CSRF и запросом, сделанным пользователем?
Разница заключается в источнике: первый отправляется с любого источника, в то время как второй отправляется с того же источника (предполагая, что ваш API и фронтенд находятся на одном источнике). Пока это можно различить на бэкенде, можно определить, какому запросу доверять.
Давайте поговорим о некоторых менее распространенных методах защиты.
Проверка заголовка Referer или Origin
Заголовок запроса содержит поле, называемое Referer, которое указывает, откуда поступает запрос. Вы можете проверить это поле, чтобы увидеть, является ли оно допустимым источником. Если нет, просто отклоните его.
Некоторые запросы также включают заголовок Origin, который означает то же самое, указывая, откуда поступает запрос.
Однако есть три момента, которые следует учитывать при использовании этого метода проверки. Во-первых, в некоторых случаях Referer или Origin могут не быть включены в запрос, так что вам нечего проверять.
Во-вторых, некоторые пользователи могут отключить функцию Referer, в этом случае ваш сервер будет отклонять запросы от добросовестных пользователей.
В-третьих, код, который определяет, является ли источник допустимым, должен быть без ошибок.
Вы заметили проблему с приведенным выше кодом? Если веб-страница содержит злоумышленника — small-min.blog.com.attack.com, ваша проверка будет обойдена.
Поэтому проверка Referer или Origin не является очень эффективным решением.
Добавление CAPTCHA или SMS-верификации
Точно так же, как при переводе денег в онлайн-банкинге, вас часто просят ввести код подтверждения, отправленный по SMS. Добавление этой дополнительной проверки может обеспечить защиту от атак CSRF. Другой вариант — использовать CAPTCHA. Поскольку злоумышленник не знает ответа на CAPTCHA, он не может продолжить атаку.
Хотя это комплексное решение, оно может повлиять на пользовательский опыт. Пользователи могут считать раздражающим необходимость вводить CAPTCHA каждый раз, когда они оставляют комментарий!
Поэтому этот метод защиты подходит для важных операций, таких как банковские переводы, изменение паролей или просмотр зарплатных ведомостей. В этих случаях следует реализовать дополнительный уровень верификации. Метод "получения SMS-кодов верификации (или электронных писем)" не только предотвращает атаки CSRF, но и защищает от XSS. Даже если хакер сможет выполнить код на странице, он не сможет получить код верификации с вашего телефона или электронной почты. Не зная кода верификации, он не сможет продолжить дальнейшие операции.
Общие методы защиты
Добавление CSRF-токена
Чтобы предотвратить атаки CSRF, нам нужно лишь убедиться, что определенная информация "известна только веб-сайту". Как мы можем этого добиться?
Мы добавляем скрытое поле, называемое csrf_token, внутри формы. Значение этого поля случайным образом генерируется сервером и должно быть уникальным для каждой отправки формы. Токен хранится в данных сессии сервера.
После отправки формы сервер сравнивает csrf_token в форме с тем, который хранится в его данных сессии. Если они совпадают, это означает, что запрос действительно был отправлен самим веб-сайтом.
Почему это работает? Потому что злоумышленник не знает значения csrf_token и не может его угадать. Поэтому он не может предоставить правильное значение, что приводит к сбою проверки на сервере и блокировке операции.
Теперь давайте рассмотрим другое решение.
Double Submit Cookie
Предыдущее решение требовало состояния на стороне сервера, что означало, что CSRF-токен должен был храниться на сервере для проверки его корректности. Преимущество этого нового решения заключается в том, что оно не требует от сервера хранения чего-либо.
Первая половина этого решения аналогична предыдущему. Сервер генерирует случайный токен и добавляет его в форму. Однако вместо того, чтобы хранить это значение в сессии, устанавливается cookie с именем csrf_token с тем же значением токена.
Как уже упоминалось ранее, основа защиты от CSRF заключается в "определении небезопасносных и легитимных запросов". Решение Double Submit Cookie основано на этой идее.
Когда пользователь отправляет форму, сервер сравнивает csrf_token в cookie с тем, который находится в форме, проверяя, есть ли у них значение и равны ли они. Таким образом, сервер может определить, был ли запрос отправлен с веб-сайта.
Почему это работает?
Предположим, злоумышленник хочет запустить атаку. Согласно принципу CSRF, упомянутому ранее, csrf_token в cookie будет отправлен на сервер. Но что насчет csrf_token в форме? Злоумышленник не может увидеть cookie целевого веб-сайта с другого источника, а также не может увидеть содержимое формы. Поэтому он не знает правильного значения.
Когда csrf_token в форме и в cookie не совпадают, атака блокируется.
Однако у этого метода есть свои недостатки, о которых будет сказано позже.
Pure Frontend Double Submit Cookie
Причина, по которой я специально упоминаю фронтенд, заключается в том, что я ранее сталкивался с проектом, который был одностраничным приложением (SPA). При поиске в интернете я нашел людей, задающих вопрос: "Как SPA может получить CSRF-токен?" Должен ли сервер предоставить для этого API? Это кажется немного странным.
Тем не менее, мы можем использовать Double Submit Cookie, чтобы решить эту проблему. Ключ к решению этой проблемы заключается в том, чтобы фронтенд генерировал CSRF-токен без какого-либо взаимодействия с серверным API.
Остальная часть процесса остается прежней: генерация токена, добавление его в форму и запись в cookie.
Почему фронтенд может генерировать этот токен? Потому что цель этого токена сама по себе не содержит никакой информации. Он предназначен только для предотвращения угадывания злоумышленником. Поэтому, независимо от того, генерируется ли он на фронтенде или бэкенде, пока его не угадают, он выполняет ту же функцию.
Основная концепция Double Submit Cookie заключается в следующем: "Злоумышленник не может читать или записывать cookie целевого веб-сайта, поэтому токен в запросе будет отличаться от токена в cookie." Пока это условие выполняется, атаку можно заблокировать.
Другие решения
Избегайте использования файлов cookie для аутентификации
Атаки CSRF полагаются на то, что браузер автоматически включает cookie в запросы, особенно cookie, используемые для аутентификации.
Поэтому, если мы не используем cookie для аутентификации, у нас не будет проблем с CSRF.
Многие веб-сайты в настоящее время принимают архитектуру разделения фронтенда и бэкенда, где фронтенд является просто статическим веб-сайтом, а бэкенд предоставляет данные только через API. Домен фронтенда и бэкенда часто различен, например, фронтенд — https://example.com, а бэкенд — https://api.example.com и т.д.
В этой архитектуре вместо традиционной аутентификации на основе cookie многие веб-сайты выбирают использование JWT (JSON Web Tokens) с HTTP-заголовками. Аутентификационный токен хранится в localStorage браузера и отправляется на бэкенд в заголовке Authorization, например:
Этот метод аутентификации полностью избегает использования cookie, что делает его невосприимчивым к атакам CSRF. Это скорее технический выбор, чем механизм защиты. Я думаю, что многие люди, выбирающие этот метод аутентификации, не осознают, что он также предотвращает CSRF.
Однако у этого метода есть и другие недостатки. Например, cookie могут быть установлены с атрибутом HttpOnly, чтобы предотвратить доступ к ним браузера, что затрудняет злоумышленникам кражу токена. Но у localStorage нет аналогичного механизма. Как только он будет скомпрометирован в результате атаки XSS, злоумышленник сможет легко украсть токен.
Добавьте пользовательские заголовки
При обсуждении атак CSRF обычно используются примеры с формами и изображениями, которые не могут включать HTTP-заголовки в запросы. Поэтому, когда вы делаете API-вызовы с фронтенда, вы можете включить пользовательский заголовок, такой как X-Version: web, чтобы позволить бэкенду определить, является ли запрос легитимным на основе наличия этого заголовка.
Хотя это может звучать неплохо, нам нужно быть осторожными с настройками CORS, как упоминалось ранее.
Помимо форм и изображений, злоумышленники также могут использовать fetch для прямой отправки Cross-Site запросов с пользовательскими заголовками, например:
Однако запросы с пользовательскими заголовками считаются непростыми запросами и требуют прохождения проверки предварительного запроса (preflight) перед их фактической отправкой. Поэтому, если ваша серверная реализация CORS корректна, этот механизм защиты будет работать нормально.
Но что, если есть проблемы с конфигурацией CORS? Тогда он не сможет защитить от атак CSRF.
Примеры из реальной жизни
Первый случай, который стоит упомянуть, — это уязвимость CSRF в Google Cloud Shell в 2022 году, обнаруженная Obmi. Существовал API для загрузки файлов без какой-либо защиты от CSRF, что позволяло злоумышленникам использовать эту уязвимость для загрузки файлов, таких как ~/.bash_profile, которые выполняли загруженные команды каждый раз, когда пользователь запускает bash.
Второй случай — это уязвимость, обнаруженная компанией Ermetic в 2023 году на Azure web service. Это довольно интересный случай.
Azure web service похож на Heroku, где вы можете развернуть веб-приложение, как только подготовите код. Эти серверы также имеют установленный по умолчанию Kudu SCM, который позволяет вам просматривать переменные окружения, настройки, загружать логи и т.д., но требует аутентификации для доступа.
Уязвимость, о которой мы говорим, была найдена в Kudu SCM. API Kudu SCM не использует CSRF-токены, а вместо этого проверяет запросы, проверяя заголовок Origin, как мы упоминали ранее.
Предположим, что URL сервера: https://example.scm.azurewebsites.net, следующие источники вернут ошибку:
https://example.scm.azurewebsites.net.attacker.com(appended)https://attacker.huli.scm.azurewebsites.net(prepended)http://example.scm.azurewebsites.net(changed to HTTP)
Хотя это кажется безнадежным, они обнаружили, что добавляя символы, отличные от _ и - в определенные позиции, они могут обойти это ограничение.
Например, https://example.scm.azurewebsites.net$.attacker.com может пройти проверку.
Однако проблема в том, что эти специальные символы не являются допустимыми доменными именами для браузеров. Так что можно сделать?
Они обнаружили, что _ может использоваться как имя поддомена, поэтому они могут построить URL, подобный этому:
С помощью этого URL они могут обойти проверку источника сервера (из-за плохо написанного регулярного выражения на сервере). После обхода проверки они начинают искать API, которые можно использовать в своих интересах, и находят один под названием /api/zipdeploy, который может напрямую развернуть сжатые файлы на сервере!
Таким образом, через эту уязвимость CSRF злоумышленник может развернуть код на веб-сервисе Azure пользователя и добиться RCE. Атака включает подготовку HTML, который вызывает API, размещеfаем его на https://example.scm.azurewebsites.net._.attacker.com, и затем отправляем его цели.
Когда цель вошла в систему и нажала на ссылку, она будет скомпрометирована.
Эту атаку они называют EmojiDeploy, потому что часть обойденного URL, ._., выглядит как эмодзи и звучит мило.
Связка уязвимостей: CSRF and self-XSS
Когда я упоминал XSS ранее, я представил тип, называемый self-XSS, который относится к XSS, который затрагивает только самого себя.
Например, если в поле номера телефона есть уязвимость XSS, но номер телефона виден только на моей личной странице настроек и не виден другим, то, если я сам не изменю номер телефона на полезную нагрузку XSS, атака не может быть запущена.
Не кажется ли вам, что это хорошая возможность объединить это с CSRF?
Предположим, что на странице личных настроек есть уязвимость CSRF, злоумышленник может использовать CSRF, чтобы изменить номер телефона жертвы на полезную нагрузку XSS, а затем открыть страницу личных настроек. Это превращает self-XSS в обычную XSS!
Исходная уязвимость self-XSS имеет небольшое влияние, и многие платформы по вознаграждению за баги могут не принять ее. Но в сочетании с CSRF она становится действительно опасной XSS.
Он нашел self-XSS на partners.uber.com, а затем объединил это с logout CSRF, выходя из текущего пользователя на домене partners.uber.com, оставаясь при этом вошедшим на домене login.uber.com.
Затем он использовал login CSRF, чтобы войти в заранее подготовленную учетную запись, вызвав XSS после входа. В этот момент, используя iframe, пользователь мог снова войти в систему, что позволяло использовать XSS для доступа к данным текущего пользователя. Это ловко связало эти уязвимости вместе, создавая более значительное воздействие.
Процесс несколько сложнее, но связь этих уязвимостей довольно интересна, а использование CSP для предотвращения перенаправления страницы также является новаторским подходом.
Заключение
Уязвимости в мире кибербезопасности взаимосвязаны. При выборе метода исправления одной уязвимости также важно учитывать влияние на другие уязвимости.
Например, "не использовать cookie для аутентификации" может решить проблему CSRF, но позволяет XSS украсть токен, увеличивая масштаб воздействия XSS. С другой стороны, "добавление пользовательского заголовка" может показаться защитой от CSRF, но если CORS настроен неправильно, этот механизм защиты становится неэффективным.
Поэтому "добавление CSRF-токена" является лучшим и более распространенным подходом. На самом деле, безопасность не ограничивается одним методом; вы можете комбинировать несколько методов, упомянутых выше.
Например, я упоминал случай HackMD во время инъекции CSS. Хотя я получил CSRF-токен, я все равно не смог запустить атаку, потому что сервер реализовал второй уровень защиты, проверяя заголовок Origin.
С другой стороны, EmojiDeploy, упомянутый ранее, является контрпримером. Они только проверяли заголовок Origin и реализовали проверку неправильно, что привело к атаке. Если бы они добавили защиту CSRF-токеном, они могли бы предотвратить атаку.
Дополнительные источники:
Last updated