CSRF-токен, необходимый при использовании аутентификации без учета состояния (= без учета)?

Нужно ли использовать CSRF Protection, когда приложение использует аутентификацию без сохранения состояния (используя что-то вроде HMAC)?

Пример:

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

Я что-то упускаю?

Я нашел некоторую информацию о CSRF +, не используя cookies для аутентификации:

  1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
    «поскольку вы не полагаетесь на cookies, вам не нужно защищать от запросов на межсайтовый сайт»

  2. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
    «Если мы идем вниз по куки-файлу, вам действительно нужно сделать CSRF, чтобы избежать запросов на межсайтовый сайт. Это то, что мы можем забыть при использовании JWT, как вы увидите».
    (JWT = Json Web Token, аутентификация на основе токена для приложений без состояния)

  3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
    «Самый простой способ сделать аутентификацию без риска уязвимостей CSRF – это просто избежать использования файлов cookie для идентификации пользователя»

  4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
    «Самая большая проблема с CSRF заключается в том, что cookies не обеспечивают абсолютно никакой защиты от такого типа атаки. Если вы используете аутентификацию cookie, вы также должны использовать дополнительные меры для защиты от CSRF. Основные меры предосторожности, которые вы можете предпринять, – это убедиться, что ваши приложение никогда не выполняет никаких побочных эффектов в ответ на запросы GET ».

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


Если вам нужно запомнить пользователя, есть два варианта:

  1. localStorage : localStorage в браузере. Сохраненные данные будут доступны даже после закрытия пользователем windows браузера. Данные недоступны другим веб-сайтам, поскольку каждый сайт получает свое собственное хранилище.

  2. sessionStorage : Также в хранилище данных браузера. Разница заключается в следующем: данные удаляются, когда пользователь закрывает окно браузера. Но это все еще полезно, если ваш webapp состоит из нескольких страниц. Таким образом, вы можете сделать следующее:

    • Пользователь регистрируется, тогда вы сохраняете токен в sessionStorage
    • Пользователь нажимает на ссылку, которая загружает новую страницу (= реальная ссылка и без содержимого javascript-replace)
    • Вы все равно можете получить доступ к токену из sessionStorage
    • Чтобы выйти из системы, вы можете вручную удалить токен из sessionStorage или дождаться, когда пользователь закроет окно браузера, которое очистит все сохраненные данные.

(для обоих смотрите здесь: http://www.w3schools.com/html/html5_webstorage.asp )


Существуют ли какие-либо официальные стандарты для авторизации токенов?

JWT (Json Web Token): Я думаю, что это все еще черновик, но он уже используется многими людьми, и концепция выглядит просто и безопасно. (IETF: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
Существуют также библиотеки для доступных лотов. Просто Google для этого!

TL; DR

JWT, если используется без Cookies, отрицает необходимость токена CSRF – НО! сохраняя JWT в сеансе / localStorage, вы подвергаете свою JWT и идентификацию пользователя, если ваш сайт обладает уязвимостью XSS (довольно распространенной). Лучше добавить ключ csrfToken в JWT и сохранить JWT в cookie с установленными атрибутами secure и http-only .

Прочтите эту статью с хорошим описанием для получения дополнительной информации https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

Вы можете сделать эту CSRF-защиту безстоящей, включив в нее иск xsrfToken JWT:

{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "[email protected]", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

Поэтому вам нужно будет сохранить csrfToken в localStorage / sessionStorage, а также в самом JWT (который хранится в http-only и secure cookie). Затем для защиты csrf убедитесь, что токен csrf в JWT соответствует представленному заголовку csrf-token.

  • Как продлить проверку подлинности ServiceStack
  • Как получить JWT?
  • ASP.NET Core 2.0 отключает автоматическую задачу
  • Микширование форм с помощью проверки подлинности Windows
  • ASP.NET Identity Cookie через поддомены
  • Аутентификация на основе токенов в ядре ASP.NET
  • Где я могу найти список URL-адресов поставщика OpenID?
  • Как я могу сделать SMTP аутентифицированным в C #
  • Базовая проверка подлинности HTTP в Node.JS?
  • Как защитить статические файлы с помощью аутентификации формы ASP.NET в IIS 7.5?
  • Аутентификация на основе токенов в ядре ASP.NET (обновлена)
  • Давайте будем гением компьютера.