Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

By default, I have CSRF protection for all my forms using a token.

However I noticed another web application that has a similar function to one of my forms. ANd they did not use CSRF token.

So I assumed they did not protect against CSRF attack for that form.

So

question 1) other than CSRF token, there should not be another way to protect against CSRF right?

I am assuming the answer is this is the only way. hence my main question is

question 2) when should you not use CSRF protection?

I know one possible instance which is when the POST form is targeted at external URLs.

I read it at django docs.

Are there other instances when you should not use CSRF protection or unnecessary?

UPDATE

a) other methods of CSRF protection include user re-authentication

b) you CAN get away without protecting against CSRF for form POSTBACKs when you do not require the user to be logged in. (see nbnh's answers and comments)

share|improve this question
    
I think it would help motivate this if you can flesh out your specific application and proposed sequence of forms in the question, as you've hinted at in some other comments. –  nealmcb Mar 13 '11 at 18:51

2 Answers 2

up vote 3 down vote accepted

No, tokens are not the only way to reliably protect against CSRF.
In fact, it was only recently that the packaged libraries were mature enough to warrant reccommendation, before that rolling your own had a high chance of making things worse.

Another way to protect against CSRF is re-authentication. I.e. asking the user for his password again.
The advantage of this approach is that the technique is familiar to the developers, and unlikely to be messed up. The disadvantage is that it is not transparent to the user.
Nowadays, with most frameworks having the protection built in, and additional libraries available, I would say that CSRF tokens are preferred... but it's not the only way.

As to Q#2, as @nhnb wrote correctly, if no modifications take place, it might be okay to leave out the protection.
Though considering how trivial it is in current frameworks, the user transparency, and the minimal overhead, you're probably better off just leaving it in, and not fighting the code to take it out...

share|improve this answer
2  
@AviD, reauthentication is not a solution that is accepted by users for CSRF protection. It may be accepted for really dangerous actions (such as transferring money), but it is not a standard solution. /// I agree that the token should not be left out just because it is not required. But it may be desirable to allow linking to form results pages. A common case is to share links to search results. –  Hendrik Brummermann Mar 12 '11 at 20:33
1  
@nhnb reauthentication is the correct solution, and the most direct. Until not so long ago, it was the only recommended solution, since rolling your own token management would always be gotten wrong, and very often create more damage than it solves. There are many examples of this used well, even outside of banks, e.g. LinkedIn. The key to that approach is being selective in where you apply it, though. –  AviD Mar 12 '11 at 22:32
    
@AviD what about an action that any anonymous visitors can perform? for eg, add item to cart without logging in. can i forego CSRF protection in this case? –  Kim Stacks Mar 13 '11 at 11:34
    
The form in question is in a template that i intend to let my users have free rein to customize the look and feel. My users are targeted at those who will be comfortable using Twig and Liquid to customize UI. Having CSRF protection means it will be less intuitive for the web designers. hence motivation behind the questions –  Kim Stacks Mar 13 '11 at 13:09
    
@keisimone as @nhnb said, if there is any "identity" that could be misused, and any "action" being performed, you should have CSRF protection. In your case you could solve this differently, be re-initializing and emptying the cart on login. –  AviD Mar 14 '11 at 6:17

Yes, using tokens is the only way to protect reliably against CSRF attacks.

Whether a protection is required or not depends on the actions the program does with the submitted data.

As a rule of thumb: If data is modified with the permissions or context of the current user, you need the protection.

If no modifications take place, it may be okay to not protect. A common example are search forms and results. Please note that logging which searches are done by which user is a kind of modification and therefore the form needs to be protected.

share|improve this answer
    
what about an action that any anonymous visitors can perform? for eg, add item to cart without logging in. can i forego CSRF protection in this case? –  Kim Stacks Mar 13 '11 at 11:33
    
For actions that anyone can perform without a user context (and without logging), it may be okay to not protect the form. But if it is in the context of a concrete user (even if it is an anonymous one), you need the protection. To expand your example in a likely way: After some time the user will enter his address and billing information and order the content of the shopping cart. For obvious reasons there shall be no items in the cart, he did not place in there himself. –  Hendrik Brummermann Mar 13 '11 at 11:44
    
i understand what you are driving at. thank you. –  Kim Stacks Mar 13 '11 at 13:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.