Hey all 🙂

So today I decided to write a new post from one of my recent simple interesting find with a much higher impact, and this is more like a case study than a technical one.

so there is an application which has 2 ways to access your account which are as follows:

1. Using email + password
2. Using social account

using both ways a user can access their account as users have explicit option to add social account like Facebook, Google in his account and once user added it, they can use any of way to access the account, and after realizing that I thought what if i get way to add my social account to the victim? that will be easier to way to get victim account access directly.

i checked both endpoints for the login flow of the social login (Facebook) option and it was same.

For Facebook login oauth flaw they were not using “state” parameter which used to protect against CSRF attack, so even while adding social account from applications users setting same flawed oauth implementation is used.

It’s very clear now that attacker just needs to make CSRF poc with his unused Facebook token generated by target application to send the victim, after successful CSRF request attackers social account will get added into victims account and attacker can login into victim account with all privileges using his own(attacker) social account.

isn’t it was simple one with much impact and turned out the highest payout for that program.

So sometimes simple login CSRF can be used to exploit in different ways with different functionality in the application, so it’s always good to be protected from everything.