• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Devaka Cooray
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Tim Holloway
  • Claude Moore
  • Stephan van Hulst
Bartenders:
  • Winston Gutkowski
  • Carey Brown
  • Frits Walraven

Session Token and CSRF (Cross-Site Request Forgery)  RSS feed

 
Ranch Hand
Posts: 387
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To avoid the CSRF attacks, it is suggested to have random tokens in the URLs. So, these tokens are same as session tokens or something else?
 
Saloon Keeper
Posts: 9857
199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not necessarily in the URL, just in the request.

The tokens are generated by the server and sent to the client before they're about to perform some sort of action. When the client submits a form or sends some other request that triggers a change, they must send the token back to the server. That way, the server will know the request came from the actual web page, and not from an attacker trying to trick somebody into sending a forged request.

The trick here is that only the web application knows what token the server sent. An attacker wouldn't know what token to send to the server.
 
Vaibhav Gargs
Ranch Hand
Posts: 387
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Stephan.

How does it differ from normal sessionid token? What will be the exact flow of messages?
 
Stephan van Hulst
Saloon Keeper
Posts: 9857
199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're implying a CSRF token is like an "abnormal session token". It has nothing to do with sessions at all, and the only thing they have in common is that they're just randomly generated strings.

I told you the flow of messages in my previous post. The server sends a web page to the client containing a CSRF token, and when the client makes a request back to the server it sends that token along with it.
 
Vaibhav Gargs
Ranch Hand
Posts: 387
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Stephan. I have few doubts regarding this :

1. How the server will generate this token and where the client will store it?

2. If it is stored in cookies at the client side, then won't it be sent along with CSRF request as cookies will also be sent across?

3. Does this mean server will keep a copy of session id as well as csrf tokens?

4. In Spring, we have disablecsrf() method, is it sufficient to call this method in Spring to eliminate CSRF risks?
 
Stephan van Hulst
Saloon Keeper
Posts: 9857
199
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's just a bunch of randomly generated bytes that are mapped to characters and encoded. There's really nothing special about it. It could be that a cryptographically secure random generator is used though.

CSRF tokens are just part of the generated HTML. They don't get stored anywhere. Usually they are placed in a hidden input field of a HTML form.

I don't know why you keep comparing session tokens to CSRF tokens, but yes, the server needs to keep track of the token it generated for a web page request.

I don't think Spring has a method called disablecsrf().
 
Any sufficiently advanced technology will be used as a cat toy. And this tiny ad contains a very small cat:
Become a Java guru with IntelliJ IDEA
https://www.jetbrains.com/idea/
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!