Csrf token что это
Перейти к содержимому

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

CSRF (cross-site request forgery, подделка межсайтовых запросов) — вид атак на сайт, при которой злоумышленник с помощью мошеннического сайта или скрипта заставляет браузер пользователя выполнять на доверенном сайте действия от его имени: отправлять сообщения, менять пароли, переводить деньги со счета на счет и пр. В атаке используются недостатки протокола HTTP.

Освойте профессию «Белый хакер»

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

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

Профессия / 13 месяцев
«Белый» хакер

Взламывайте ПО безнаказанно и за оплату

cables_2 2-PhotoRoom 1 (2)

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

Разобраться, как работает межсайтовая подделка запросов, поможет понятие сессионных cookies (куки).

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

После сохранения браузер отправляет cookies на сервер с каждым запросом и идентифицирует пользователя. С их помощью злоумышленник может выдать себя за потенциальную жертву и заставить ее браузер выполнить запрос. Если пользователь уже авторизован на сайте, cookies отправятся автоматически вместе с запросом.

Для выполнения CSRF необходимы несколько условий:

  • на уязвимом сайте есть действие, которое хакер хочет выполнить от имени жертвы, например изменить адрес @mail, осуществить перевод денежных средств, изменить пароль и так далее;
  • злоумышленник заранее знает все параметры запроса, которые ожидает увидеть уязвимый сайт. Даже незначительное отличие в тексте повлияет на работоспособность;
  • действие полагается только на файлы cookies для верификации пользователя и выполняется с помощью HTTP-запросов.

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

Либо злоумышленник может обманом заставить жертву загрузить или отправить информацию. Например, через фишинговую ссылку.

Она может быть скрыта в теге изображения:

Или замаскирована под обычную ссылку:

Станьте специалистом
по кибербезопасности – научитесь отражать кибератаки и поддерживать безопасность любых IT-систем

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

Некоторые фреймворки имеют встроенную защиту от CSRF-атак. Например .NET или Laravel. Если ее нет, можно использовать следующие способы.

SOP

SOP (same-origin policy, политика одинакового источника) определяет то, как именно скрипт или документ, который загружен из оригинального источника (origin), будет взаимодействовать с ресурсом, загруженным из другого источника. Две страницы имеют одинаковый источник, если у них совпадают хост (host), порт (port) и протокол (http или https). Часто можно встретить также запись вида scheme/host/port tuple. Это позволяет изолировать документы, которые могут нанести вред, и снизить количество вероятных векторов атак.

Токены CSRF

CSRF-токены (или anti-CSRF-токены) напоминают cookies. Это такие же данные, которые сервер отправляет браузеру в ожидании получить их обратно, но отличие в следующем: сервер должен отправить браузеру уникальный токен и проверить, присылает ли его браузер в ответ в запросе. Если токены совпадают, запрос действителен, если нет — отклоняется.

Токен должен удовлетворять требованиям:

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

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

Флаг Same-Site Cookies

Метод похож на использование SOP. Отличие в том, что флаг Same-Site помечает куки для одного доменного имени. В результате источник запроса подвергается проверке. Считается, что cookies и источник запроса имеют одинаковое происхождение, если протокол, порт (если применимо) и хост (но не IP-адрес) одинаковы для обоих. Таким образом не получится отправить запрос с мошеннического сайта. Флаг поддерживает подавляющее большинство современных браузеров, и его использование является хорошей практикой в стратегии защиты.

Подтверждение действий от пользователя

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

«Белый» хакер

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

Атака 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-параметр или дополнительное поле.

Межсайтовая подделка запроса: защита от CSRF атак

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

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

Обычно для этого пользователь должен перейти по мошеннической ссылке (которая может быть изменена с помощью сокращателя ссылок).

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

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

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

Методы GET, HEAD, OPTIONS и TRACE не подвержены CSRF, потому что предназначены только для получения информации и не изменяют состояние сервера.

Методы POST, PUT, DELETE и PATCH должны быть защищены от CSRF.

Cookies сессии

Cookies сессии — это способ, которым протокол HTTP отслеживает состояние. Веб-сайты используют cookies для идентификации пользователей и сохранения их данных.

После сохранения cookies, браузер отправляет их на сервер с каждым запросом, чтобы идентифицировать пользователя.

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

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

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

Для того, чтобы злоумышленник осуществил атаку CSRF, нужны определённые условия:

  • В приложении есть действие, которое злоумышленник хочет предпринять – например, изменить пароль, перевести средства и так далее.
  • Не существует непредсказуемых параметров запроса – злоумышленник может угадать (или знать) все параметры, которые приложение ожидает увидеть из этого типа запроса.
  • Действие может быть выполнено с помощью HTTP-запросов, и оно полагается только на файлы cookie, чтобы убедиться, что запрос исходит от пользователя.

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

Либо нужно начать с того, что злоумышленник обманом заставит жертву загрузить или отправить информацию в веб-приложение. Это может произойти несколькими способами – например, через фишинговую ссылку.

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

Вот пример атаки через обычную ссылку:

Или через тэг изображения:

Способы защиты от CSRF атак

Выбор защищённых фреймфорков

Используйте фреймворки, которые имеют встроенную защиту против CSRF, например .NET. Также важно правильно настроить фреймворк. Если ваш фреймворк не имеет защиты от CSRF вы можете использовать Anti-CSRF токены.

Anti-CSRF токены

Токены (или synchronizer token) – это способ защиты со стороны сервера. Сервер генерирует случайный уникальный токен для браузера пользователя и проверяет его для каждого запроса.

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

Токен должен удовлетворять следующим условиям:

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

Использование двух токенов

Смысл этого метода в том, что используются два токена: первый сохраняется в cookies, а второй — в одном из параметров ответа.

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

Использование флага Same-Site в сookies

Этот флаг помечает куки для определенного домена.

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

Этот флаг поддерживает большинство браузеров. Его стоит использовать как часть общей стратегии защиты от CSRF атак.

Требуйте подтверждения от пользователя

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *