• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Cross Site Request Forgery (CSRF)

 
Ranch Hand
Posts: 2379
MySQL Database Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I started with the entry in http://en.wikipedia.org/wiki/Cross-site_request_forgery to understand what is CSRF and how to prevent it. I see people talking about preventing CSRF attack through token generation. I should say that it's still not very clear to me and wanted to have some discussions with you on this.

I understand that we can generate some security tokens for ave the timestamp for each user session and next time a request comes, check against that token and timestamp. However, what I am not understanding (in a broad sense) is how it is different from just using a regular session attribute or using a cookie. The steps to use token as far as my understanding goes are -

1) Generate a token, use md5 or random number or anything that an attacker can't guess on.
2) Use a hidden field in the form (for POST) or a URL parameter (for GET) as token value where you can put the generated token's value.
3) For each user request, determine if the token is already present there or not and match that with the token value (and time stamp with a safe time-to-live) of session attribute/request attribute.

This means, I have to add the logic of checking this into a filter or controller where I can inject the token or check the condition of the token validation.

But what about checking a first time user request? At that time, the new session is created, right? So the first page must be shown as the token is not present. So if I have already shown the first page or executed the first URL, then I failed to prevent a CSRF attack for that first page/URL. Is that okay?

If you put some comments that will help me clarify my thoughts and understanding on this topic. Thanks in advance.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The first page -where a session is created- would typically be the page after the login. That would presumably require the user to have sent username and password, something he needs to type in - that can't be done through a CSRF.
 
reply
    Bookmark Topic Watch Topic
  • New Topic