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

• Что такое CSRF
• Чем CSRF отличается от других атак
• Как работает межсайтовая подделка запросов 
• Пример CSRF-атаки
• Какие HTTP запросы подвержены CSRF атаке
• Как должны генерироваться CSRF токены
• Как передавать CSRF токены
• Как проверять CSRF токены
• Как защитить сайт от CSRF-атак

Что такое CSRF

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

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

Чем CSRF отличается от других атак

Как работает межсайтовая подделка запросов 

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

1. Пользователь входит на сайт и проходит процесс аутентификации, после чего получает сессионный токен или куки, которые используются для подтверждения его личности при последующих запросах.
2. Пользователь случайно или намеренно переходит на сайт, который контролируется злоумышленником. 
3. Вредоносный сайт создает скрытый запрос к легитимному сайту. Он может быть внедрен в виде изображения, формы или скрипта, который выполняется автоматически при загрузке страницы.
4. Браузер пользователя, не различая легитимные и поддельные запросы, автоматически отправляет сформированный запрос к легитимному сайту вместе с учетными данными пользователя.
5. Легитимный сайт принимает запрос и выполняет запрашиваемое действие, так как запрос выглядит как корректным и исходит от аутентифицированного пользователя.

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

Представим ситуацию: пользователь авторизовался на сайте онлайн-банка. Тогда злоумышленник отправляет пользователю электронное письмо со ссылкой на вредоносный сайт. 

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

Какие HTTP запросы подвержены CSRF атаке

CSRF-атакам могут подвергаться различные виды HTTP-запросов, но наиболее уязвимыми являются те, которые изменяют состояние сервера или содержат важные данные. К ним относятся POST, PUT, DELETE и PATCH:

• POST-запросы обычно используются для отправки данных на сервер с целью создания или изменения ресурсов. Примеры таких запросов: отправка форм, создание новых записей в базе данных или выполнение финансовых транзакций. Поскольку эти запросы часто содержат важные данные и могут изменять состояние системы, они часто становятся целями для CSRF-атак.
• PUT-запросы используются для обновления существующих ресурсов на сервере. Они могут менять данные пользователя, обновлять информацию о продукте или изменять настройки системы. 
• DELETE-запросы применяют, чтобы удалять ресурсы с сервера. Например, удалять учетные записи пользователей, файлы или записи из базы данных. 
• PATCH-запросы используют для частичного обновления ресурсов на сервере. Они могут изменять отдельные поля в записи, обновлять конфигурации и выполнять другие важные действия, а потому также уязвимы для CSRF-атак

Некоторые HTTP-запросы менее подвержены CSRF-атакам, так как они не изменяют состояние сервера или не содержат важные данные. К таким запросам относятся GET, HEAD, OPTIONS и TRACE. Они обычно используются для получения метаданных или проверки доступности ресурсов и не изменяют состояние сервера, поэтому гораздо реже становятся целью для CSRF-атак

Как должны генерироваться CSRF токены

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

1. Во-первых, CSRF token должны генерироваться с использованием криптографически безопасного генератора псевдослучайных чисел (CSPRNG). Он обеспечивает высокую степень случайности и непредсказуемости токенов. В качестве начального состояния CSPRNG может использовать комбинацию отметки времени, когда токен был создан, и статического секретного ключа, известного только серверу. Благодаря этому токен становится уникальным, и тогда его очень тяжело предсказать или подделать.
2. Во-вторых, чтобы повысить уровень безопасности, введите элементы пользовательской энтропии. Например, при генерации CSRF-токенов можно объединить выход CSPRNG с уникальными характеристиками пользователя: его идентификатор сессии или IP-адрес. Полученная структура затем подвергается криптографическому хешированию, что создаст дополнительный барьер для злоумышленника, который пытается проанализировать или подделать токены.

Такая методология не только увеличивает непредсказуемость токенов, но и добавляет слой защиты от атак, которые используют известные образцы данных. Хеширование объединенной структуры также защищает от возможных утечек информации, которая могла бы быть использована для обратного анализа токенов.

Как передавать CSRF токены 

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

Передача через скрытое поле формы

Наиболее распространенный и безопасный метод передачи CSRF-токенов – это включить их в скрытое поле HTML-формы, которая отправляется с использованием метода POST. Тогда токен передается только при отправке формы и не доступен в URL-строке.

Чтобы обеспечить дополнительную безопасность, рекомендуется размещать поле с CSRF-токеном в HTML-документе как можно раньше. Например, перед любыми видимыми полями ввода и местами, где данные, которые контролируются пользователем, встроены в HTML. Так вы сможете защититься от различных атак, при которых злоумышленник попытается манипулировать HTML-документом и захватить содержимое CSRF-токена.

Риск передачи через URL

Альтернативный метод передачи CSRF-токенов – через строку запроса URL. Однако он считается менее безопасным по следующим причинам:

1. Строки запросов URL могут регистрироваться в журналах как на стороне клиента, так и на стороне сервера. Это увеличивает риск утечки токенов.
2. Строки запросов могут передаваться третьим лицам в заголовке HTTP Referer, что может привести к утечке CSRF-токена.
3. Строки запросов могут отображаться в адресной строке браузера – это делает их доступными для просмотра и копирования. 

Передача через пользовательские заголовки

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

Хотя этот подход улучшает безопасность, он ограничивает выполнение CSRF-защищенных запросов использованием XHR, а потому не подходит для некоторых приложений.

Возможна ли передача в файлах cookie

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

Как проверять CSRF токены

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

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

1. Сервер извлекает CSRF-токен из полученного запроса. Токен может быть передан в скрытом поле формы, заголовке HTTP или в параметре URL.
2. После извлечения токена из запроса сервер сравнивает его с токеном, который хранится в данных сеанса пользователя. Если токены совпадают, запрос считается валидным.
3. Проверка CSRF-токенов выполняется независимо от HTTP-метода или типа содержимого запроса. Таким образом защита применяется ко всем потенциально опасным запросам.
4. Если запрос не содержит CSRF-токен или токен неверен, сервер отклоняет такой запрос. Тем самым он предотвращает атаки, при которых злоумышленник пытается отправить поддельные запросы от имени пользователя.

Как защитить сайт от CSRF-атак

Используйте CSRF-токены

Один из наиболее эффективных способов защиты от CSRF-атак – это использование CSRF-токенов. Они генерируются сервером и встраиваются в каждую форму, которая отправляет данные на сервер. 

Когда пользователь отправляет форму, токен передается вместе с данными запроса. Сервер проверяет токен на соответствие значению, сохраненному в сеансе пользователя. Если токен не совпадает, запрос отклоняется. 

Проверяйте заголовки Origin и Referer

Еще один метод защиты – проверка заголовков Origin и Referer. Когда браузер отправляет запрос, эти заголовки указывают, с какого сайта был инициирован запрос. Сервер может использовать эту информацию для проверки того, что запросы поступают с доверенных доменов. 

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

Ограничьте методы HTTP

Веб-приложения должны минимизировать использование методов HTTP, которые могут изменять состояние сервера, таких как POST, PUT, DELETE и PATCH. 

Для операций, которые не изменяют данные, следует использовать методы GET и HEAD. Кроме того, важно убедиться, что сервер корректно обрабатывает запросы и не выполняет действия, которые не были разрешены.

Используйте атрибута SameSite для куки

Атрибут SameSite для куки помогает ограничить их отправку только при запросах с того же сайта. Установка этого атрибута для куки-сессии снижает риск успешной CSRF-атаки, так как браузер не будет отправлять куки при запросах, которые инициированы с других сайтов. 

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

Внедрите двухфакторной аутентификации (2FA)

Двухфакторная аутентификация (2FA) добавляет дополнительный уровень защиты, требуя от пользователя подтверждения действий через второй канал, например, с помощью SMS или приложения-аутентификатора. Этот метод усложняет выполнение CSRF-атак, так как злоумышленник должен будет получить доступ и к дополнительному способу аутентификации.

Проводите регулярные обновления и мониторинг

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

Заключение 

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