Опубликовано: пятница, 31 марта 2023 г. в 09:12

CSRF: Обход проверки токена

Security

Источник: «Bypassing CSRF token validation»

В этой статье мы разберёмся, что такое CSRF токены, как они защищают от 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 токены не нужно отправлять в качестве скрытых параметров в запросе POST. Например, некоторые приложения помещают CSRF токены в HTTP заголовки. Способ передачи токенов оказывает значительное влияние на безопасность механизма в целом. Дополнительные сведения см. в статье CSRF: Как предотвратить уязвимость.

Общие недостатки проверки CSRF токена

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

Валидация CSRF токена зависящая от метода HTTP запроса

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

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

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

Валидация CSRF токена в зависимости от наличия токена

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

В этой ситуации злоумышленник может удалить весь параметр, содержащий 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=pwned@evil-user.net

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

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

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

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=wiener@normal-user.com

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

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

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

Ещё один вариант предыдущей уязвимости заключается в том, что некоторые приложения не ведут никаких записей на стороне сервера о выданных токена, а вместо этого дублируют каждый токен в 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=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com

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