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

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

Пример:

  • У нас есть одностраничное приложение (в противном случае мы должны добавить токен на каждую ссылку: <a href="...?token=xyz">...</a>.

  • Пользователь аутентифицируется, используя POST /auth. При успешной аутентификации сервер вернет некоторый токен.

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

  • Этот токен будет использоваться для доступа к ограниченным URL-адресам, таким как /admin.

  • Маркер всегда будет передаваться внутри заголовков HTTP.

  • Там нет сеанса Http и NO Cookies.

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

Я что-то пропустил?

Ответ 1

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

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

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

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

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

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


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

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

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

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

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


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

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

Ответ 2

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.