Обход проверки CSRF-токена
Что такое CSRF-токен?
CSRF-токен — это уникальное, секретное и непредсказуемое значение, которое генерируется серверным приложением и передаётся клиенту. При отправке запроса на выполнение чувствительного действия, например отправки формы, клиент должен включить корректный CSRF-токен. В противном случае сервер откажется выполнять запрошенное действие.
Распространённый способ передать CSRF-токены клиенту — включать их как скрытый параметр в HTML-форму, например:
<form name="change-email-form" action="/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="example@normal-website.com">
<input required type="hidden" name="csrf" value="50FaWgdOhi9M9wyna8taR1k3ODOR8d6u">
<button class='button' type='submit'> Update email </button>
</form>Отправка этой формы приводит к следующему запросу:
POST /my-account/change-email HTTP/1.1
Host: normal-website.com
Content-Length: 70
Content-Type: application/x-www-form-urlencoded
csrf=50FaWgdOhi9M9wyna8taR1k3ODOR8d6u&email=example@normal-website.comПри корректной реализации CSRF-токены помогают защититься от атак CSRF, затрудняя для атакующего конструирование валидного запроса от имени жертвы. Поскольку у атакующего нет способа предсказать корректное значение CSRF-токена, он не сможет включить его во вредоносный запрос.
Распространённые ошибки в проверке CSRF-токенов
Проверка CSRF-токена зависит от метода запроса
Некоторые приложения корректно проверяют токен, когда запрос использует метод POST, но пропускают проверку при использовании метода GET.
В этой ситуации атакующий может переключиться на метод GET, чтобы обойти проверку и провести атаку CSRF:
Проверка CSRF-токена зависит от наличия токена
Некоторые приложения корректно проверяют токен, когда он присутствует, но пропускают проверку, если токен убран вовсе.
В этой ситуации атакующий может удалить весь параметр, содержащий токен (а не только его значение), чтобы обойти проверку и провести атаку CSRF:
CSRF-токен не привязан к пользовательской сессии
Некоторые приложения не проверяют, что токен принадлежит той же сессии, что и пользователь, отправляющий запрос. Вместо этого приложение поддерживает глобальный пул выданных токенов и принимает любой токен, который в нём встречается.
В этой ситуации атакующий может войти в приложение под своей учётной записью, получить валидный токен и затем подставить этот токен жертве в своей атаке CSRF.
CSRF-токен привязан к несессионному cookie
В вариации предыдущей уязвимости некоторые приложения действительно привязывают CSRF-токен к cookie, но не к тому cookie, который используется для отслеживания сессий. Это легко происходит, когда приложение использует два разных фреймворка — один для управления сессиями и один для защиты от CSRF, — которые не интегрированы между собой:
Эту ситуацию сложнее эксплуатировать, но она по-прежнему уязвима. Если на сайте есть какое-либо поведение, позволяющее атакующему устанавливать cookie в браузере жертвы, то атака возможна. Атакующий может войти в приложение под своей учётной записью, получить валидный токен и связанный cookie, воспользоваться функциональностью установки cookie, чтобы поместить свой cookie в браузер жертвы, и подставить свой токен жертве в атаке CSRF.
CSRF-токен просто дублируется в cookie
В дальнейшей вариации предыдущей уязвимости некоторые приложения не ведут серверный учёт выданных токенов, а вместо этого дублируют каждый токен в cookie и параметре запроса. При последующей проверке запроса приложение просто сверяет, что токен, отправленный в параметре запроса, совпадает со значением, отправленным в cookie. Это иногда называют защитой «double submit» от CSRF; её рекомендуют, поскольку она проста в реализации и не требует какого-либо серверного состояния:
В этой ситуации атакующий снова может провести атаку CSRF, если на сайте есть какая-либо функциональность установки cookie. Здесь атакующему даже не нужно получать собственный валидный токен. Он просто придумывает токен (возможно, в требуемом формате, если это проверяется), использует функциональность установки cookie, чтобы поместить свой cookie в браузер жертвы, и подставляет свой токен жертве в атаке CSRF.
Last updated