0

I am adding CSRF prevention mechanism to my application. I have look through many posts but just still have uncertainties in my approach. I am going to use the synchronized token implementation at the same time I want to use it to prevent double submit, back button and refresh. so I will need a new token for every request. Currently in my app, there are the regular form submit, url GET and AJAX requests. There are actually some new-window popups, but I am trying eliminate/rewrite those functions. Here is what I am planing to do along with some uncertainties.

Here is some preliminary assumptions:

  1. under normal circumstances no two functions will send request to server at same time from one user
  2. prevented all XSS
  3. cannot access cookie with JavaScript
  4. using HTTPS

My flow and doubts:

  1. token will be generated and stored in session then passed along with generated HTML or JSON data. Will value transmitted through header be as secure as inserting it in HTML or JSON?
  2. every request will carry this token to be matched against the value stored in session. will passing this value through header be of any problem?
  3. in order to minimize my programmers' work, I want to provide uniform JavaScript functions to submit form and make AJAX call so I can add the token on the request transparently. Therefore, I plan to put the token in a JavaScript variable which will definitely be accessible by all JavaScript programs. Is there any risk for doing this?

Does my approach have the "self-contained" problem?

Thanks

lunaspeed
  • 165
  • 1
  • 11

1 Answers1

0

1 & 2: Only matter regarding the security of the CSRF tokens as they travel over the wire is HTTPS VS HTTP. If its just http someone can intercept the communication and your CSRF tokens.

Other than that, its the same data being transported. There's no difference if its in the header or inside a JSON or HTML. Just make sure the tokens are communicated over HTTPS. With HTTPS, even the headers are encrypted.

If it's HTTP without SSL, a man-in-the-middle attack will find it anyway, whether it's in the header or within HTML.

3. AJAX to deal with the CSRF tokens is not a good idea. An attacker can use the ajax call as an attack vector. Instead, if there is something you really don't want an attacker to CSRF on such as credit card transactions, it would be better to make the user log in again.

Community
  • 1
  • 1
sajawikio
  • 1,516
  • 7
  • 12
  • ok I am confident about point 1 and 2 now. for what I meant for point 3 is that I want to place my token on a JavaScript variable and update it with every AJAX call I made, and not explicitly dealing with the token using AJAX. I suppose placing the token as a JS variable and placing it in a hidden input is the same thing right? – lunaspeed Aug 13 '13 at 10:34