CSRF Token necessary when using Stateless(= Sessionless) Authentication?

132
votes

Is it necessary to use CSRF Protection when the application relies on stateless authentication (using something like HMAC)?

Example:

  • We've got a single page app (otherwise we have to append the token on each link: <a href="...?token=xyz">...</a>.

  • The user authenticates himself using POST /auth. On successful authentication the server will return some token.

  • The token will be stored via JavaScript in some variable inside the single page app.

  • This token will be used to access restricted URLs like /admin.

  • The token will always be transmitted inside HTTP Headers.

  • There's NO Http Session, and NO Cookies.

As far as I understand, there should(?!) be no possibility to use cross site attacks, because the browser won't store the token, and hence it cannot automatically send it to the server (that's what would happen when using Cookies/Session).

Am I missing something?

2
authenticationcsrfsingle-page-applicationstatelesscsrf-protection
Be careful about Basic Auth. Many browsers will automatically send the basic auth headers for the rest of the session. This can make basic auth as vulnerable to CSRF as cookie auth. – phylae

2 Answers

163
votes

I found some information about CSRF + using no cookies for authentication:

  1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
    "since you are not relying on cookies, you don't need to protect against cross site requests"

  2. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
    "If we go down the cookies way, you really need to do CSRF to avoid cross site requests. That is something we can forget when using JWT as you will see."
    (JWT = Json Web Token, a Token based authentication for stateless apps)

  3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
    "The easiest way to do authentication without risking CSRF vulnerabilities is to simply avoid using cookies to identify the user"

  4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
    "The biggest problem with CSRF is that cookies provide absolutely no defense against this type of attack. If you are using cookie authentication you must also employ additional measures to protect against CSRF. The most basic precaution that you can take is to make sure that your application never performs any side-effects in response to GET requests."

There are plenty more pages, which state that you don't need any CSRF protection, if you don't use cookies for authentication. Of course you can still use cookies for everything else, but avoid storing anything like session_id inside it.

If you need to remember the user, there are 2 options:

  1. localStorage: An in-browser key-value store. The stored data will be available even after the user closes the browser window. The data is not accessible by other websites, because every site gets its own storage.

  2. sessionStorage: Also an in browser data store. The difference is: The data gets deleted when the user closes the browser window. But it is still useful, if your webapp consists of multiple pages. So you can do the following:

    • User logs in, then you store the token in sessionStorage
    • User clicks a link, which loads a new page (= a real link, and no javascript content-replace)
    • You can still access the token from sessionStorage
    • To logout, you can either manually delete the token from sessionStorage or wait for the user to close the browser window, which will clear all stored data.

(for both have a look here: http://www.w3schools.com/html/html5_webstorage.asp )

Are there any official standards for token auth?

JWT (Json Web Token): I think it's still a draft, but it's already used by many people and the concept looks simple and secure. (IETF: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
There are also libraries for lot's of framework available. Just google for it!

63
votes

TL;DR

A JWT, if used without Cookies, negates the need for a CSRF token - BUT! by storing JWT in session/localStorage, your expose your JWT and user's identity if your site has an XSS vulnerability (fairly common). It is better to add a csrfToken key to the JWT and store the JWT in a cookie with secure and http-only attributes set.

Read this article with a good description for more info https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

You can make this CSRF protection stateless by including a xsrfToken JWT claim:

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

So you will need to store the csrfToken in localStorage/sessionStorage as well as in the JWT itself (which is stored in a http-only and secure cookie). Then for csrf protection, verify that the csrf token in the JWT matches the submitted csrf-token header.