Является ли это безопасным способом предотвращения атак типа Cross-Site Request Forgery (CSRF)?

Наше приложение:

  • Каждый пользователь должен войти в систему
  • страница входа в систему возвращается на сервер, и если авторизованный пользователь возвращает приложение SPA.
  • Приложение SPA полностью AJAX
  • HTTPS

Обычно мы отправляем cookie sessionid и cookie csrftoken. Значение cookie Token будет включаться в качестве x-заголовка на любые сообщения AJAX и все, проверенные на сервере по каждому запросу.

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

Что мы будем делать:

  • отправьте sessionid как файл cookie, как раньше, но имя файла cookie будет случайным.
  • no csrftoken, но вместо этого вставьте случайное имя файла cookie в подпрограмму javascript, которая добавила x-заголовок к сообщениям AJAX.
  • сервер получит sessionid из x-заголовка.

Это дает нам возможность разрешить несколько логинов, причем каждый вход в систему имеет уникальное имя cookie sessionid, но каждый пост-запрос имеет стандартизованное имя заголовка x.

Будет ли это безопасно, как файл cookie sessionid, метод csrftoken cookie/x-header?

Ответы

Ответ 1

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

например. X-Requested-With может быть добавлен к каждому запросу AJAX (JQuery делает это по умолчанию), и вы просто проверяете, что этот заголовок присутствует, когда запрос получен с одной стороны. Этот заголовок не может быть отправлен в междоменном домене без выбора сервера через CORS.

Вы можете совместить это с токеном - см. мой ответ здесь.

например.

X-Requested-With: XMLHttpRequest;0123456789ABCDEF