2

We know that cookies with httpOnly and secure flag are immune to XSS and vulnerable to CSRF attacks. And at the same time we know that local storage is vulnerable to XSS, but can protect against CSRF.

So, what if we combine them in this manner:

1) Use access JWT token with csrftoken property in its payload and store this token in httpOnly and secure cookie and

2) Use csrftoken and store it in local storage. JWT token and csrftoken are submitted to a client on successful authorization. Browser submits JWT token to the server on each request and application passes scrftoken in a header. Server checks if csrftoken from JWT and header match and if not - blocks the request.

It seems like this scheme will protect us from both types of attacks. Malicious code injected to a page will not get access to JWT token (so no XSS) and malicious code run by a user outside our site will not force this user submit his/her csrftoken in a header (so, no CSRF).

So, I wonder if is a good practice and do they use this scheme in real world applications.

Jeroen
  • 5,783
  • 2
  • 18
  • 26
Jacobian
  • 207
  • 1
  • 3
  • 13
  • This sounds like a novel concept to me. But, I don't understand the purpose of doing this(or why this is better than current practice of keeping xss and csrf protection separate). You are sending CSRF token with every request anyway and setting both cookie flags(httponly and secure) for the JWT token. – ramailo sathi Sep 01 '17 at 04:47
  • This only applies when you use session based anti CSRF tokens. You don't have this problem when using request based anti CSRF tokens. – Jeroen Sep 01 '17 at 05:47
  • @Jeroen - IT Nerdbox. Could you, please, a bit elaborate on how session based anti CSRF tokens differ from request based anti CSRF tokens? I'm not quite sure what it may mean. – Jacobian Sep 01 '17 at 06:56
  • In session based anti CSRF token, the anti CSRF token is always the same during the entire session. In request based anti CSRF tokens, in each request, a new anti CSRF token is generated. – Jeroen Sep 01 '17 at 07:01
  • In my scheme CSRF token will stay the same as long as access JWT token is not expired. – Jacobian Sep 01 '17 at 07:03
  • And when I rotate or reissue access token, I also provide the client with a new csrftoken – Jacobian Sep 01 '17 at 07:04
  • The likelihood of a token being stolen in a requests based anti CSRF mechanism is quite slim and should solve your issue. I suggest you look in to that. There are however some common issues with request based anti CSRF tokens in a-sync connections (to API's for example) – Jeroen Sep 01 '17 at 07:05

0 Answers0