Обход проверки 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="[e-mail]">
    <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=[e-mail]

При корректной реализации CSRF-токены помогают защититься от атак CSRF, затрудняя для атакующего конструирование валидного запроса от имени жертвы. Поскольку у атакующего нет способа предсказать корректное значение CSRF-токена, он не сможет включить его во вредоносный запрос.

Note

CSRF-токены необязательно отправлять как скрытые параметры в POST запросе. Некоторые приложения, например, помещают CSRF-токены в HTTP (протокол передачи гипертекста) заголовки. Способ передачи токенов существенно влияет на безопасность механизма в целом.

Подробности см. в разделе Как предотвращать уязвимости CSRF

Распространённые ошибки в проверке CSRF-токенов

Проверка CSRF-токена зависит от метода запроса

Некоторые приложения корректно проверяют токен, когда запрос использует метод POST, но пропускают проверку при использовании метода GET.

В этой ситуации атакующий может переключиться на метод GET, чтобы обойти проверку и провести атаку CSRF:

GET /email/change?email=[e-mail] HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

LAB

CSRF where token validation depends on request method

Проверка CSRF-токена зависит от наличия токена

Некоторые приложения корректно проверяют токен, когда он присутствует, но пропускают проверку, если токен убран вовсе.

В этой ситуации атакующий может удалить весь параметр, содержащий токен (а не только его значение), чтобы обойти проверку и провести атаку CSRF:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
email=[e-mail]

LAB

CSRF where token validation depends on token being present

CSRF-токен не привязан к пользовательской сессии

Некоторые приложения не проверяют, что токен принадлежит той же сессии, что и пользователь, отправляющий запрос. Вместо этого приложение поддерживает глобальный пул выданных токенов и принимает любой токен, который в нём встречается.

В этой ситуации атакующий может войти в приложение под своей учётной записью, получить валидный токен и затем подставить этот токен жертве в своей атаке CSRF.

LAB

CSRF where token is not tied to user session

CSRF-токен привязан к несессионному cookie

В вариации предыдущей уязвимости некоторые приложения действительно привязывают CSRF-токен к cookie, но не к тому cookie, который используется для отслеживания сессий. Это легко происходит, когда приложение использует два разных фреймворка — один для управления сессиями и один для защиты от CSRF, — которые не интегрированы между собой:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv
csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=[e-mail]

Эту ситуацию сложнее эксплуатировать, но она по-прежнему уязвима. Если на сайте есть какое-либо поведение, позволяющее атакующему устанавливать cookie в браузере жертвы, то атака возможна. Атакующий может войти в приложение под своей учётной записью, получить валидный токен и связанный cookie, воспользоваться функциональностью установки cookie, чтобы поместить свой cookie в браузер жертвы, и подставить свой токен жертве в атаке CSRF.

LAB

CSRF where token is tied to non-session cookie

Note

Функциональность установки cookie даже не обязана находиться в том же веб-приложении, где присутствует уязвимость CSRF. Любое другое приложение в пределах одного и того же DNS (система доменных имён) домена потенциально можно использовать для установки cookie в целевом приложении, если контролируемый cookie имеет подходящую область действия. Например, функцию установки cookie на staging.demo.normal-website.comможно использовать для помещения cookie, который отправляется на secure.normal-website.com.

CSRF-токен просто дублируется в cookie

В дальнейшей вариации предыдущей уязвимости некоторые приложения не ведут серверный учёт выданных токенов, а вместо этого дублируют каждый токен в cookie и параметре запроса. При последующей проверке запроса приложение просто сверяет, что токен, отправленный в параметре запроса, совпадает со значением, отправленным в cookie. Это иногда называют защитой «double submit» от CSRF; её рекомендуют, поскольку она проста в реализации и не требует какого-либо серверного состояния:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa
csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=[e-mail]

В этой ситуации атакующий снова может провести атаку CSRF, если на сайте есть какая-либо функциональность установки cookie. Здесь атакующему даже не нужно получать собственный валидный токен. Он просто придумывает токен (возможно, в требуемом формате, если это проверяется), использует функциональность установки cookie, чтобы поместить свой cookie в браузер жертвы, и подставляет свой токен жертве в атаке CSRF.

LAB

CSRF where token is duplicated in cookie