Csrf token что это

Методы защиты от CSRF-атаки

Ознакомиться с самой идеей атаки CSRF можно на классических ресурсах:

Выдержка из ответа на SO:

Причина CSRF кроется в том, что браузеры не понимают, как различить, было ли действие явно совершено пользователем (как, скажем, нажатие кнопки на форме или переход по ссылке) или пользователь неумышленно выполнил это действие (например, при посещении bad.com , ресурсом был отправлен запрос на good.com/some_action , в то время как пользователь уже был залогинен на good.com ).

Как от нее защититься?

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

Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.

А что, собственно, защищать?

Если вы пишете свой Web-Сервис в соотвествии со стандартом RFC7231, то методы GET , HEAD , OPTIONS и TRACE являются безопасными: они предназначены только для получения информации и не должны изменять состояние сервера.

Таким образом, защищать необходимо небезопасные методы, к которым относятся: POST , PUT , DELETE , PATCH .

На Habrahabr опубликована статья от Yandex, в которой описано, почему писать свои сервисы нужно, руководствуясь стандартом.

Требования к токену:

• Уникальный токен для каждой операции
• Действует единожды
• Имеет размер, устойчивый к подбору
• Сгенерирован криптографически стойким генератором псевдослучайных чисел
• Имеет ограниченное время жизни

На первом MeetUp’е PDUG Тимур Юнусов (руководитель отдела безопасности банковских
систем Positive Technologies) рассказывал, почему именно такие требования предъявляются к CSRF-Токену и чем грозит пренебрежение ими.

Требования к Web-Сервису и окружению:

• Отсутствие XSS уязвимостей
  Внедренный злоумышленником скрипт имеет возможность отправлять запрос к серверу от имени пользователя и читать его без каких-либо препятствий.
  Таким образом, XSS уязвимости могут быть использованы для получения текущего токена.
• Отсутствие malware на машине клиента
  Если злоумышленник имеет возможность запускать софт на машине клиента, то он может получить любые данные, имеющиеся в браузере.

Методы защиты

Существует 3 метода использования токенов для защиты web-сервисов от CSRF атак:

• Synchronizer Tokens (Statefull)
• Double Submit Cookie (Stateless)
• Encrypted Token (Stateless)

Synchronizer Tokens

Простой подход, использующийся повсеместно. Требует хранения токена на стороне сервера.

Суть:

1. При старте сессии на стороне сервера генерируется токен.
2. Токен кладется в хранилище данных сессии (т.е. сохраняется на стороне сервера для последующей проверки)
3. В ответ на запрос (который стартовал сессию) клиенту возвращается токен.
   Если рендеринг происходит на сервере, то токен может возвращаться внутри HTML, как, например, одно из полей формы, или внутри тега.
   В случае, если ответ возвращается для JS приложения, токен можно передавать в header (часто для этого используют X-CSRF-Token )
4. При последующих запросах клиент обязан передать токен серверу для проверки.
   При рендере контента сервером токен принято возвращать внутри POST данных формы.
   JS приложения обычно присылают XHR запросы с header ( X-CSRF-Token ), содержащим токен.
5. При получения запроса небезопасным методом ( POST , PUT , DELETE , PATCH ) сервер обязан проверить на идентичность токен из данных сессии и токен, который прислал клиент.
   Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:

• Защита от CSRF на хорошем уровне
• Токен обновляется только при пересоздании сессии, а это происходит, когда сессия истекает
  Во время жизни одной сессии все действия будут проверяться по одному токену.
  Если произойдет утечка токена, то злоумышленник сможет выполнить CSRF-Атаку на любой запрос и в течение долгого срока. А это не есть хорошо.
• Бесплатная поддержка multi-tab в браузере.
  Токен не инвалидируется после выполнения запроса, что позволяет разработчику не заботиться о синхронизации токена в разных табах браузера, так как токен всегда один.

Double Submit Cookie

Этот подход не требует хранения данных на стороне сервера, а значит, является Stateless. Используется, если вы хотите уметь быстро и качественно масштабировать свой Web-сервис горизонтально.
Идея в том, чтобы отдать токен клиенту двумя методами: в куках и в одном из параметров ответа (header или внутри HTML).

Суть:

1. При запросе от клиента на стороне сервера генерируется токен. В ответе токен возвращается в cookie (например, X-CSRF-Token ) и в одном из параметров ответа (в header или внутри HTML).
2. В последующих запросах клиент обязан предоставлять оба полученных ранее токена. Один как cookie, другой либо как header, либо внутри POST данных формы.
3. При получении запроса небезопасным методом ( POST , PUT , DELETE , PATCH ) сервер обязан проверить на идентичность токен из cookie и токен, который явно прислал клиент.
   Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:

• Stateless CSRF защиту.
• Необходимо учитывать, что поддомены могут читать cookie основного домена, если явно это не запрещать (т.е. если cookie установлена на .site.ru , то её могут прочитать как a.site.ru , так и b.site.ru ).
  Таким образом, если ваш сервис доступен на домене 3-го уровня, а злоумышленник имеет возможность зарегистрировать свой ресурс на вашем домене 2-го уровня, то устанавливайте cookie на свой домен явно.
• Нюансы зависят от реализации

Encrypted Token

Так же как и Double Submit, является Stateless подходом. Основная — если вы зашифруете надежным алгоритмом какие-то данные и передадите их клиенту, то клиент не сможет их подделать, не зная ключа. Этот подход не требует использования cookie. Токен передаётся клиенту только в параметрах ответа.

В данном подходе токеном являются факты, зашифрованные ключом. Минимально необходимые факты — это идентификатор пользователя и timestamp времени генерации токена. Ключ не должен быть известен клиенту.

Суть:

1. При запросе от клиента на стороне сервера генерируется токен.
   Генерация токена состоит в зашифровке фактов, необходимых для валидации токена в дальнейшем.
   Минимально необходимые факты — это идентификатор пользователя и timestamp. В ответе токен возвращается в одном из параметров ответа (В header или внутри HTML).
2. В последующих запросах клиент обязан предоставлять полученный ранее токен.
3. При получения запроса небезопасным методом ( POST , PUT , DELETE , PATCH ) сервер обязан валидировать токен, полученный от клиента.
   Валидация токена заключается в его расшифровке и сравнения фактов, полученных после расшифровки, с реальными. (Проверка timestamp необходима для ограничения времени жизни токена)
   Если расшифровать не удалось либо факты не совпадают, считается, что запрос подвергся CSRF-Атаке.

На выходе имеем:

• Stateless CSRF защиту
• Нет необходимости хранить данные в cookie
• Нет нюансов с поддоменами.

О реализации

• Давайте генерировать новый токен на каждый запрос, не важно, каким HTTP-методом и с какой целью этот запрос сделан.
  Таким образом мы получаем токен, который меняется постоянно.
  Конечно, возникает вопрос организации multi-tab работы.
  Синхронизация токенов между табами может быть реализована с использованием localStorage и его StorageEvent
• Ограничиваем время жизни cookie, которое содержит токен, разумным значением. Например 30 минут.
• Делаем cookie недоступной из JS (ставим HTTPOnly=true)
• Используем TLS для предотвращения MITM
  При этом отправляем cookie только по HTTPS (ставим Secure=true)
• Размер токена не менее 32 байт.
• Генерируем токен криптографически стойким генератором псевдослучайных чисел.
  Для этого можно использовать системные функции:

Linux => getrandom(2) если возможно, /dev/urandom иначе OpenBSD => getentropy(2) На других Unix-like системах => /dev/urandom Windows => CryptGenRandom API

Что еще нужно знать?

Токены — обязательная защита от CSRF.

• Проверяйте, но не полагайтесь только на X-Requested-With: XMLHttpRequest
• Проверяйте, но не полагайтесь только на заголовки: Host , Origin , Referer
• Не передавайте токены в URL
• Защищайте все запросы.

Same Site

Сейчас идет работа над спецификацией атрибута «Same-Site» у cookies (последняя версия на момент написания статьи).

Такой атрибут даст возможность разработчикам явно указывать, что cookie не нужно передавать, если запрос идет с сайта, отличного от того, на котором cookie была установлена. А, значит, у нас появится возможность защищать ресурсы от CSRF без использования дополнительных инструментов.

Браузер Chrome уже сейчас поддерживает эту возможность.

Чуть больше информации о том, как и почему доступно на Stack Exchange.

• csrf
• безопасность веб-приложений

Атака CSRF

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Нельзя говорить про AJAX и не упомянуть про важнейшую деталь его реализации – защиту от CSRF-атак.

CSRF (Cross-Site Request Forgery, также XSRF) – опаснейшая атака, которая приводит к тому, что хакер может выполнить на неподготовленном сайте массу различных действий от имени других, зарегистрированных посетителей.

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

Злая форма

«Классический» сценарий атаки таков:

• Вася является залогиненным на сайт, допустим, mail.com . У него есть сессия в куках.
• Вася попал на «злую страницу», например хакер пригласил его сделать это письмом или как-то иначе.
• На злой странице находится форма такого вида:

Итог атаки – Вася, зайдя на злую страницу, ненароком отправил письмо от своего имени. Содержимое письма сформировано хакером.

Защита

В примере выше атака использовала слабое звено авторизации.

Куки позволяют сайту mail.com проверить, что пришёл именно Вася, но ничего не говорят про данные, которые он отправляет.

Иначе говоря, куки не гарантируют, что форму создал именно Вася. Они только удостоверяют личность, но не данные.

Типичный способ защиты сайтов – это «секретный ключ» ( secret ), специальное значение, которое генерируется случайным образом при авторизации и сохраняется в сессии посетителя. Его знает только сервер, посетителю мы его даже не будем показывать.

Разумеется, для разных посетителей secret будет разным.

Затем на основе ключа генерируется «токен» ( token ). Токен делается так, чтобы с одной стороны он был отличен от ключа secret , в частности, может быть много токенов для одного ключа, с другой – чтобы было легко проверить по токену, сгенерирован ли он на основе данного ключа или нет.

Для этого для каждого токена используется дополнительное случайное значение, которое называют «соль» salt .

Формула вычисления токена:

token = salt + ":" + MD5(salt + ":" + secret)

1. В сессии хранится secret=»abcdef» , это значение создаётся один раз.
2. Для нового токена сгенерируем salt , например пусть salt=»1234″ .
3. token = «1234» + «:» + MD5(«1234» + «:» + «abcdef») = «1234:5ad02792a3285252e524ccadeeda3401» .

Это значение – с одной стороны, случайное, с другой – получив такой token от пользователя, мы можем его проверить: разбить по символу двоеточия, взять его левую часть 1234 в качестве salt и, зная secret , запустить вычисление по формуле выше. Если мы получили то же самое, то token правильный, это не хакер.

Обратим внимание: не зная secret , невозможно сгенерировать token , который сервер воспримет как правильный.

Далее, токен добавляется в качестве скрытого поля к каждой форме, генерируемой на сервере.

То есть, «честная» форма для отсылки сообщений, созданная на http://mail.com , будет выглядеть так:

При её отправке сервер проверит поле csrf , удостоверится в правильности токена, и лишь после этого отошлёт сообщение.

«Злая страница» при всём желании не сможет сгенерировать подобную форму, так как не владеет secret , и токен будет неверным.

Такой токен также называют «подписью» формы, которая удостоверяет, что форма сгенерирована именно на сервере.

Подпись с полями формы

Эта подпись говорит о том, что автор формы – сервер, но ничего не гарантирует относительно её содержания.

Есть ситуации, когда мы хотим быть уверены, что некоторые из полей формы посетитель не изменил самовольно. Тогда мы можем включить в MD5 для формулы токена эти поля, например:

token = salt + ":" + MD5(salt + ":" + secret + ":" + fields.money)

При отправке формы сервер проверит подпись, подставив в неё известный ему secret и присланное значение fields.money . При несовпадении либо secret не тот (хакер), либо fields.money изменено.

Токен и AJAX

Теперь перейдём к AJAX-запросам.

Что если посылка сообщений в нашем интерфейсе реализуется через XMLHttpRequest?

Как и в случае с формой, мы должны «подписать» запрос токеном, чтобы гарантировать, что его содержимое прислано на сервер именно интерфейсом сайта, а не «злой страницей».

Здесь возможны варианты, самый простой – это дополнительная кука.

1. При авторизации сервер устанавливает куку с именем CSRF-TOKEN , и пишет в неё токен.
2. Код, осуществляющий XMLHttpRequest, получает куку и ставит заголовок X-CSRF-TOKEN с ней:

var request = new XMLHttpRequest(); var csrfCookie = document.cookie.match(/CSRF-TOKEN=([\w-]+)/); if (csrfCookie)

Защита действует потому, что прочитать куку может только JavaScript с того же домена. «Злая страница» не сможет «переложить» куку в заголовок.

Если нужно сделать не XMLHttpRequest, а, к примеру, динамически сгенерировать форму из JavaScript – она также подписывается аналогичным образом, скрытое поле или дополнительный URL-параметр генерируется по куке.

Итого

• CSRF-атака – это когда «злая страница» отправляет форму или запрос на сайт, где посетитель, предположительно, залогинен. Если сайт проверяет только куки, то он такую форму принимает. А делать это не следует, так как её сгенерировал злой хакер.
• Для защиты от атаки формы, которые генерирует mail.com , подписываются специальным токеном. Можно подписывать не все формы, а только те, которые осуществляют действия от имени посетителя, то есть могут служить объектом атаки.
• Для подписи XMLHttpRequest токен дополнительно записывается в куку. Тогда JavaScript с домена mail.com сможет прочитать её и добавить в заголовок, а сервер – проверить, что заголовок есть и содержит корректный токен.
• Динамически сгенерированные формы подписываются аналогично: токен из куки добавляется как URL-параметр или дополнительное поле.

Token CSRF как защита от CSRF-атак

Эта статья научит вас, как исправить ошибку «CSRF token истёк», которую вы можете получить при посещении сайта, и больше расскажет о CSRF-атаках в целом.

Что такое CSRF

CSRF (от англ. cross-site request forgery) или межсайтовая подделка запроса – это форма атаки на любой сайт или веб-приложение. С помощью подделки запросов мошенник обманом заставляет пользователя выполнять нежелательные действия на, казалось бы, проверенной платформе.

Как работает CSRF-атака

Межсайтовая подделка запроса будет работать только в том случае, если потенциальная жертва авторизована. Благодаря этому злоумышленник может обойти процесс аутентификации, чтобы войти в веб-приложение.

Выполнение CSRF-атаки состоит из двух основных частей.

1. Злоумышленник заставляет жертву щёлкнуть на ссылку или загрузить веб-страницу. Он намеренно заманивает пользователя перейти по ссылке, используя методы социальной инженерии.
2. Отправляет «поддельный» или выдуманный запрос в браузер жертвы. Вредоносная ссылка отправит запрос в веб-приложение, однако будет включать в себя значения, которые выгодны злоумышленнику.

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

Примеры CSRF-атаки

Для того, чтобы получить ответ от сервера, в протоколе применяют различные методы HTTP-запросов. Наиболее часто используемые – это GET, POST, PUT, PATCH и DELETE.

Они используются и для создания межсайтовой подделки запроса.

Пример GET CSRF-атаки:

В следующем примере показано, как выглядит типичный GET-запрос для банковского перевода в размере 1000 долларов.

GET https://randombank.ru/transfer.do?account=RandPerson&amount=$1000 HTTP/1.1

Злоумышленник может изменить ссылку таким образом, что она приведёт к переводу 1000 долларов на его личный счет. Вредоносный запрос будет выглядеть так:

GET https://randombank.ru/transfer.do?account=SomeAttacker&amount=$1000 HTTP/1.1

Если задействованное приложение ожидает GET-запрос, злоумышленник может разместить на своем веб-сайте тег, который вместо ссылки на изображение отправит поддельный запрос.

Пример POST CSRF-атаки:

Вы выиграли приз!

1. Пользователь входит на сайт www.shopshop.ru с помощью своих логина и пароля.
2. Сервер авторизует пользователя, а ответ от сервера включает файл cookie аутентификации.
3. Не выходя из системы, пользователь посещает вредоносную веб-страницу. Этот сайт содержит HTML-форму, указанную выше.
4. Пользователь нажимает кнопку отправки. Браузер отправляет файл cookie аутентификации вместе с запросом.
5. Сервер обрабатывает запрос, учитывая, что пользователь уже находится в аккаунте, поэтому злоумышленник получает доступ ко всему, что разрешено делать авторизованному пользователю.

Что такое токен CSRF

Токен CSRF – это уникальное и непредсказуемое значение, которое сервер генерирует для защиты уязвимых перед CSRF ресурсов.

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

Таким образом, можно выделить основные признаки токена CSRF:

• уникальность при каждом запросе;
• непродолжительное время жизни,
• непредсказуемость и устойчивый к подбору.

Ошибки CSRF: почему возникают и как их исправить?

Сообщения «Неверный токен CSRF» или «Срок действия токена CSRF истёк» означает, что ваш браузер не смог создать безопасный файл cookie или не смог получить доступ к этому файлу cookie для авторизации вашего входа в систему.

Это может быть вызвано плагинами, расширениями, блокирующими рекламу, а также самим браузером, если ему не разрешено устанавливать файлы cookie.

Есть несколько причин, по которым вы можете получать сообщения об ошибках:

• срок действия старого токена действительно истёк, так как прошло более 24 часов;
• уже был отправлен новый токен, в связи с чем старый стал недействительным;
• плагины или расширения блокируют запросы;
• браузеру не разрешено устанавливать файлы cookie.

Иногда нужно лишь обновить свою страницу или вновь войти в систему, и всё будет готово для продолжения вашей работы. Если это не помогает, есть способы исправить это в разных браузерах.

Как исправить ошибки CSRF в браузерах

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

1. В панели слева откройте вкладку Конфиденциальность и безопасность.
2. Выберите Файлы cookie и другие данные сайтов.

1. Пролистайте до раздела «Специальные настройки» и щёлкните Добавить рядом с графой «Сайты, которые всегда могут использовать файлы cookie».
2. Чтобы включить сайт в этот список, введите название нужного сайта по форме [*.]ваш.сайт и затем нажмите Добавить.

1. В разделе Посмотреть все разрешения и данный сайтов найдите nic.ru и удалите все записи, связанные с сайтом.
2. Перезагрузите браузер и вновь войдите на сайт.

1. Откройте меню в правом верхнем углу экрана и щёлкните Настройки.
2. В параметрах перейдите в раздел Файлы cookie и разрешения сайтов.
3. Нажмите «Управляйте файлами cookie и данными сайта…».

1. Нажмите Добавить рядом со словом «Разрешить», чтобы внести сайт в список и позволить браузеру сохранять с него файлы cookie.
2. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
3. Перейдите во вкладку Посмотреть все файлы cookie и данные сайта и удалите всё, связанное с выбранным сайтом.

1. Перезагрузите браузер.

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

1. В левой панели выберите вкладку Сайты и найдите в ней опцию Расширенные настройки сайтов.
2. Пролистайте вниз до раздела Cookie-файлы. Откройте Настройки сайтов под ним.
3. Нажмите Добавить.

1. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
2. Вернитесь на предыдущую страницу и перейдите в Cookie-файлы и данные сайтов. Кнопка находится рядом с Настройками сайтов.
3. Удалите все данные о сайте.
4. Перезагрузите браузер.

1. В левой панели экрана щёлкните на значок Настроек.
2. Выберите раздел Безопасность, а затем нажмите Файлы cookie и прочие данные сайтов.

1. В разделе «Настраиваемое поведение» у параметра Сайты, которые всегда могут использовать файлы cookie щёлкните Добавить.

1. Введите [*.]ваш.сайт и подтвердите своё решение, нажав Добавить.
2. Чуть выше выберите опцию Все файлы cookie и данные сайта и удалите все данные о сайте.
3. Перезагрузите ваш браузер и вновь откройте сайт.

1. Откройте Настройки Safari в верхней части экрана или с помощью сочетания клавиш Cmd + ,.
2. Перейдите на вкладку Конфиденциальность и убедитесь, что для параметра «Файлы cookie и данные веб-сайтов» не установлено значение «Блокировать все файлы cookie».
3. Затем нажмите Управлять данными веб-сайта…, найдите [ваш.сайт] и удалите все записи, связанные с сайтом.
4. Перезагрузите Safari и проверьте сайт на наличие ошибки.

Заключение

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

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

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

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

Что такое CSRF токен

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

Обычный способ поделиться CSRF токенами с клиентом — включить их в качестве скрытого параметра в HTML-форму, например:

form name="change-email-form" action="/my-account/change-email" method="POST"> 
label>Emaillabel> 
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 атаке.

Дополнительные материалы

• CSRF: Подделка межсайтовых запросов
• CSRF: Как предотвратить уязвимость
• В чём разница между XSS и CSRF
• CSRF: Обход защиты основанной на Referer