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

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

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

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

Часть 17 | Защита от CSRF без сохранения состояния

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

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

Техника двойной отправки файлов cookie

Подобно шаблону токена синхронизатора, метод двойной отправки файлов cookie — это способ реализации токенов таким образом, что злоумышленники не имеют к ним доступа, а законные веб-страницы имеют. Вот как это работает:

  1. Файлы cookie уникальны для данного домена (и, возможно, поддоменов).
  2. Файлы cookie могут быть прочитаны JavaScript, если для предотвращения этого не используется атрибут HttpOnly.
  3. Вместо того, чтобы сохранять токен на сервере, он включается в ответ как файл cookie, поэтому он сохраняется в браузере пользователя. Это удобно для конфигураций сервера, в которых сохранение токена проблематично, например, когда конфигурация не имеет состояния. С помощью метода двойной отправки файла cookie сервер может вообще забыть о маркере.
  4. Больше нет необходимости вручную связывать токен, который хранится в виде файла cookie, с пользователем через сеансы, чтобы предотвратить атаки, когда злоумышленник получает свой собственный токен и включает его в запросы CSRF. Вместо этого тот факт, что файл cookie хранится в браузере пользователя, связывает этот файл cookie с этим пользователем.
  5. Для запросов на изменение состояния сервер по-прежнему требует, чтобы токен был отправлен с использованием скрытых полей формы, заголовков или других механизмов в дополнение к этому файлу cookie. Идея состоит в том, что JavaScript будет включен на страницу, которая находит файл cookie, в котором хранится токен, и обеспечивает его добавление вторым способом при отправке запроса.

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

С точки зрения данного сервера, он знает, что запрос является законным, если он включает файл cookie с токеном в дополнение к заголовку, полю формы или другому вводу с тем же токеном. Это верно, потому что:

  1. При нормальных обстоятельствах только заголовки ответа от сервера или JavaScript, обслуживаемый из домена сервера, могут хранить файл cookie для этого домена. Поэтому, если во входящий запрос включен файл cookie с токеном, сервер может предположить, что он установил этот файл cookie в прошлом, даже если он не может вспомнить. Это, конечно, исключает XSS-атаки на домен сервера, неиспользование пользователями стандартного браузера или другие аномалии.
  2. Если полученный запрос содержит тот же токен во второй форме, это означает, что запрос должен быть инициирован страницей, принадлежащей домену сервера. В конце концов, только страницы, принадлежащие этому домену, могут использовать JavaScript для доступа к файлу cookie, в котором хранится токен, и добавить его в запрос вторым способом.

Поздравляем. Теперь вы знаете основы техники двойной отправки файлов cookie. Об этой технике можно сказать еще много, но это выходит за рамки данной статьи.

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

Ежедневный совет:

Если метод двойной отправки файла cookie — это слишком далеко, вы можете изучить метод пользовательского заголовка. Это также не имеет состояния и даже проще, чем техника, описанная здесь!

Спасибо, что читаете вместе! Есть время читать дальше? В следующей статье мы обсудим наш .