Login/logout CSRF: Time to reconsider?

My stance on login/logout CSRF has changed. I, like many others, used to quickly dismiss them as a non-security issue. Some bug bounty programs even explicitly removes them from the scope. However, there are several situations where they could become a security issue:

SSO provider example

Let’s say that applicationX is an OAUTH provider, which has login/logout CSRF. ApplicationY implements “Connect with ApplicationX”. After connecting your ApplicationX account, you may use it to authenticate at ApplicationY.

This becomes a problem in this scenario:

1. Attacker CSRF logs out victim from ApplicationX
2. Attacker CSRF logs in victim at ApplicationX (victim now logged in as attacker at ApplicationX)
3. Attacker sends victim to “Connect with ApplicationX” functionality
4. The attacker’s ApplicationX account is now connected to the victims ApplicationY account
5. The attacker uses “Log in with ApplicationX” to authenticate as the victim on ApplicationY

Stored self-xss example

Imagine that ApplicationX has login/logout CSRF. It also has a stored XSS on the http://ApplicationX/editprofile page. This seems harmless, since the stored XSS will only ever fire on your own http://ApplicationX/editprofile page.

This becomes a problem in this scenario:

1. Attacker stores XSS payload on their http://ApplicationX/editprofile page
2. Attacker creates a page on their domain, containing 2 iframes.
2.1. The first iframe loads http://ApplicationX/sensitivedata
2.2. After the first iframe loads, a second iframe loads logout CSRF
2.3. The second iframe then loads login CSRF
2.4. The second iframe then loads http://ApplicationX/editprofile
2.5. The second iframe (which now fires the stored XSS) reads the contents of the first iframe. This is possible since both frames are on the same origin.
3. Attacker makes victim visit the page
4. Attacker now has the contents of victims http://ApplicationX/sensitivedata

This attack works because when http://ApplicationX/sensitivedata is loaded, the victim is logged into their own account. When http://ApplicationX/editprofile is loaded, the victim is logged into the attacker’s account.

Here’s an example of a similar attack on Uber:
https://whitton.io/articles/uber-turning-self-xss-into-good-xss/

Data collection example

Quite a while back, I discovered that reddit was vulnerable to login/logout CSRF. The previous examples did not apply, however it was possible to spy on users like so:

1. Attacker creates a new account
2. Attacker buys reddit gold
3. Attacker turns on “save links between computers” feature
4. Attacker CSRF logout the victim
5. Attacker CSRF login the victim into the new account
6. Any link the victim clicks or votes on will be stored in the new account, available for the attacker to read

Here’s an example from way back of a similar bug on YouTube:
http://blog.jeremiahgrossman.com/2008/09/i-used-to-know-what-you-watched-on.html

Is the security impact of CSRF login/logout situational? Sure. But so is missing httponly flag, deserializing user data without a gadget available, missing XFO etc. So why should we ignore login/logout CSRF?

Read more of Mathias’ previous write-ups here.