I am making a web application in Django which generates and includes CSRF tokens for sessions (a Django session can be anonymous or a registered user). Should I keep CSRF protection to the controllers handling login and logout action?
Possibly you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the attacker to effectively hijack requests to the domain that the victim thought were anonymous or were under their own account and then sending it to the attacker's account. Of course whether this is relevant to your particular site or not depends on the nature of your site and whether something like this is advantageous to an attacker. An example is a Login CSRF attack on a search engine so the attacker can see the terms being searched for as they are logged under the attacker's account instead of the victim's.
You should also protect your logout mechanism against CSRF. At first it seems that all an attacker can do is logout the user, which would be annoying at worst. However, if you combine this with a phishing attack, the attacker may be able to entice the victim to re-login in using their own form and then capture the credentials. See here for a recent example - LostPass.
CSRF Protection on Logout is a must !
Why? Assume the following scenario:
- You're on a trading page and prepare a buying order for e.g. 1000 Daimlers on an Exchange XETRA.
- Until you are preparing the order, somebody, who knows that you are logged on https://anybrokerpage.com/ , sends a phishing link to you. e.g. https://anybrokerpage.com/logout
- By clicking the link, you are logged out and the order is perhaps not finished.
- After logging in again, you recognize that the price for the 1000 Daimlers is higher than a minute before you logged out by this phishing link.
- Now you have to order a higher price.
A CSRF Token on the logout would have prevented this mess.
Login? Yes. Logout? No.
Why login? There is this funny CSRF login attack, where the attacker logs in the victim under aa attacker-controlled account, and then can "gain control over content created by the victim while logged in under that account". The impact is pretty lame IMO, but they started to see this as a problem now that more juicy attack vectors are gone. ;-)
Why not logout? There is no security impact. The best one can do is to log someone out of the system, which causes annoyance at most.
EDIT: There is no security impact in logout CSRF attack by itself. There may be cases when this may be used in a multi-stage attack to first log someone out, then prompt them to log in on a spoofed page.
Logout and login CSRF is actually very exploitable.
If you find a way to get a permanent private/self XSS (such as an unsecured private field like in user preferences) you can force log out the victim, login in with your account which has the self XSS applied, and then execute some code to make a phishing attack except it's on the correct domain with a valid SSL cert. If the user logs in (or has auto fill which would allow you to steal their credentials before they even hit submit AND then auto login for them so they may just see their page flash white and then they'll be where they expect) you now have their password and a same origin execution. Now just run some exploit persistence in their private settings and now you've got permanent remote JS execution on the users account.
This allows very major attacks especially since many developers don't both with HTML injection exploits on private fields because only the user should be able to see that and they have no reason to execute code against themselves. A login logout CSRF exploit let's you perform same origin phishing and if they have same origin iframes enabled you can also embed the login page full screen and then execute whatever code you want inside the seemingly legit iframe.
Any of the bugs alone range from useless to annoying at best but if you have these two (and it's best to always assume you do) an attacker can hijack a users account with just one nasty ad.