https://security.stackexchange.com/questions/115766/is-a-jwt-usable-as-a-csrf-token
https://insidethecpu.files.wordpress.com/2013/09/encrypted-token-pattern.pdf
http://www.redotheweb.com/2015/11/09/api-security.html
Taken from: https://security.stackexchange.com/questions/115766/is-a-jwt-usable-as-a-csrf-token
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": "tom@andromeda.com",
"xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}
So you will need to store the csrfToken in local/sessionStorage and inside the JWT claim, then, you need to store the in JWT in a http-only and secure cookie. For csrf protection, verify that the csrf token in the JWT matches the submitted csrf-token header.
Additional notes
The JWT is passed with every request without having to manually add it in. The csrfToken is left in the localstorage - so can't be accessed by CSRF. However, maybe we can do the opposite. Have the JWT in localstorage. It can't be accessed by CSRF. If XSS is employed - then the attacker can use it. However, if it's short lived, they cannot use it for long. Plus - if we want extra protection, the JWT in local storage holds the secret to the CSRF token. The CSRF token is in a non-javascript readable Http-only cookie - so a script can't access it. When this is sent to the server, the server checks both the JWT's CSRFToken claim and the Http-only cookie. Bob's your uncle.
http://forum.serverless.com/t/how-to-send-a-cookie-as-a-response/1312
From: http://stackoverflow.com/questions/35291573/csrf-protection-with-json-web-tokens
Storing the authen token in HTML5 Storage means:
- (-) Risk of it getting stolen in an XSS attack.
- (+) Provides CSRF
- (-) Must manually modify each request going to the server, limiting you to SPA (eg AngularJs) web applications.
On the other hand, if you store the authn token in a cookie marked httpOnly and secure, then:
- (+) The authn token cannot be stolen by XSS.
- (-) You will have to provide CSRF protection yourself. Implementing CSRF protection is easier in some frameworks than others.
Which option is better depends on your needs.
Does your authn token protect anything to do with money? You'll probably want the cookie httpOnly secure option.
Is the level of effort required to implement CSRF protection not worth the assets it's protecting? Then the HTML5 storage might be the right place.
From: sahat/satellizer#833
Send a xsrf-token cookie to the Angular client without the HttpOnly flag. Because of same-origin policy, only JavaScript sent from same origin as the cookie will be able to read the cookie. Sure malicious CSRF scripts can send the cookie back to the server, but the server doesn't do anything with the cookie so it doesn't matter. Angular performing a $http request will read the xsrf-token and return it to the server as a x-xsrf-token header.
Here is the magic. Create a JWT that is stored in a different cookie called token. This cookie does have the HttpOnly flag set so no JavaScript can read it. Within the payload of this JWT is the xsrf-token in the other cookie. Of course, because the JWT is signed, the xsrf-token in the JWT can't be altered.
The next request to the server will contain a x-xsrf-token header and a cookie that has a JWT token that has that xsrf-token in the signed payload. Therefore, to verify the request all the server has to do is make sure the xsrf-token in the header is the same as the xsrf-token in the JWT in the other cookie.
Double Submit Cookie and Encrypted Token Pattern
https://www.ibm.com/developerworks/library/se-prevent/
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/