Cool little trick against the NodeBB oauth flow resulting in a CSRF that would associate an attackers third-party account with a victim NodeBB account.

If you’re not familiar with Oauth flows, the basic idea is that you login to a third party auth provider (like Google for example). Google does their thing, and then assuming all is okay, redirects you back to the original application (NodeBB) with a code in the URL. NodeBB can then go ahead and exchange that code for information about your Google account and associate it with your NodeBB account.

The problem is in that association process, NodeBB assumed anyone coming to the url with a code that worked on Google must want that account associated with the account they are currently logged in as. So an attacker could get this code legitimately for their own Google account, and then trick or coerce a victim user using CSRF into visiting the url with the attackers code. Allowing the attacker’s account to be associated with the victim’s NodeBB account.

Ideally the state parameter should have been used, which would provide a unique value in the redirect to the auth provider, that it would return back with the code. Preventing CSRF by requiring a unique value that the attacker wouldn’t know, and providing a mechanism to verify the code is being assoicated with the correct account.