29

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?

christophetd
  • 217
  • 1
  • 12
Jesvin Jose
  • 499
  • 1
  • 5
  • 10
  • 5
    Sites like `http://superlogout.com/` actually use the fact that most sites don't have logout CSRF. (before clicking the link: it will call out to major sites, like GMail or EBay and call the appropriate logout endpoint to log you out) – SztupY Apr 02 '15 at 13:16
  • [Here's a practical example](https://fin1te.net/articles/uber-turning-self-xss-into-good-xss/) that uses CSRF on the login and logout functions of Uber to exploit a XSS vulnerability. – Sjoerd Mar 23 '16 at 15:42

6 Answers6

34

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.

The main targets for this type of attack is where authenticated actions can take place outside of the main application itself. e.g. from a browser plugin or widget embedded on another site. This is because these actions will be authenticated through the use of cookies, and if an attacker has you logged in as them each action will be recorded in their account.

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.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • 3
    Also: Depending on what your app does and/or how this logout can be triggered, this could become a DoS that chases customers away. – Scott Arciszewski Jan 01 '16 at 07:07
  • 3
    @SilverlightFox : Actually adding``to a page will log you out of every google services. So If they let this, it’s certainly because csrf for logging out isn’t a significant threat. – user2284570 Jul 03 '16 at 22:17
  • @SilverlightFox Are you saying: The victim logins with the attacker credentials? So the attacker made logged in the victim in his own bank account? Seems like a unique attack... – Alboz Jul 14 '17 at 09:21
  • @Alboz: It might be possible in a payment scenario. Say there was a "generate payment link" function in a widget where you can grab a link to your payment provider's site to enable people to deposit money by sending them the link. If the attacker logged you in as them then every time you generated a link and it was used it would deposit money in the attacker's account instead of yours. – SilverlightFox Jul 14 '17 at 10:23
  • @SilverlightFox that's a very creative mental scenario but completely not realistic and impossible as in that case there would be other protections in place. Anyway what I'm trying to say is that this is only needed for specific type of websites. Not every web app needs to care about reverse CSRF on login... The only case I've heard is Youtube and the attacker used it to just see what videos the victim watched... People are reading your answer and thinking that even private web apps with no defense for reverse CSRF are at risk.. which is not true. – Alboz Jul 14 '17 at 11:57
  • @alb Good point. Answer edited. – SilverlightFox Jul 14 '17 at 12:35
  • @SilverlightFox Good I can up-vote you now. It is important to give the correct information as many people take any accepted answer here as a "must implement". This is more of an attack for public web sites rather than Enterprise Web Applications where the attacker must be one of employees who attacks another colleague. – Alboz Jul 14 '17 at 13:41
7

CSRF Protection on Logout is a must !

Why? Assume the following scenario:

  1. You're on a trading page and prepare a buying order for e.g. 1000 Daimlers on an Exchange XETRA.
  2. 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
  3. By clicking the link, you are logged out and the order is perhaps not finished.
  4. 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.
  5. Now you have to order a higher price.

A CSRF Token on the logout would have prevented this mess.

S.L. Barth
  • 5,486
  • 8
  • 38
  • 47
security-guest
  • 71
  • 1
  • 1
  • 2
    You don't even need to click the link. All the "attacker" need is some site you visit which allows user to include images from external domains (forum, other forms of social media sites FE.). Viewing the "image" `https://anybrokerpage.com/logout` would log you out. – SleepProgger Feb 22 '16 at 18:07
  • This seems like an argument for POST logout, but not necessarily a CSRF-protected logout. – jwhitlock Apr 30 '18 at 14:02
  • Really strange argument for CSRF in my opinion. The whole Attack in this case was performed by someone to divert your attention, caused you to re-login, waste time and buy on a higher price??? Imagine someone attempting that same plot, only this time around, when you relogin, the price dropped (due to a newly found Diamond Mine in South African ) by 50%. God bless the hacker ! – JAR.JAR.beans May 14 '19 at 09:05
5

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.

Allison
  • 3,975
  • 2
  • 13
  • 19
5

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.

Dmitry Janushkevich
  • 992
  • 5
  • 10
  • 1
    If you implement CSRF correctly you shouldn't even have to protect each field seperately. It should be part of your framework. – Lucas Kauffman Jul 09 '14 at 07:53
  • Surely you meant "each form"? – Dmitry Janushkevich Jul 09 '14 at 08:03
  • Yep, that's what I meant – Lucas Kauffman Jul 09 '14 at 08:03
  • Could you elaborate on "gain control over content created by the victim"? – Jesvin Jose Jul 09 '14 at 08:47
  • 3
    Suppose you are the attacker. You create an account on a vulnerable system and thus, obviously, can access the account and anything related to it. Then you conduct the login CSRF attack against the victim. Suppose the victim creates a "secret" document while logged in under the controlled account and stores it there. Then, you automatically have access to the document by virtue of having access to the account he created. The attack is weak and requires quite some preparations, but looks somewhat plausible. – Dmitry Janushkevich Jul 09 '14 at 09:00
  • You can DOS the user by logging them out all the time. This is a security impact. – ysdx Nov 25 '20 at 15:00
3

CSRF for login generally yes but does depend on your application. an attacker can log you into a malicious account eg in Google and then monitor all your site visits.

CSRF for logout - yes absolutely can prevent DOS

Darragh
  • 1,102
  • 9
  • 15
0

Logout CSRF can be useful when chaining with other exploits.

For example, there is a web application I am testing on, which use WAF for more protection. This website have a redirect loop that pointing to their login page. Therefore, when user access the redirect loop, their browser will call /login page many times and make WAF locks them from accessing /login page for 1 hour. It does not matter because they already logged in. However, if I use logout CSRF to kick them out after WAF locked them. Then it is a problem, and I did exactly that.

trieulieuf9
  • 31
  • 4