The SpoofedMe social login exploit is a known weakness of the OAuth2 “spec”. The OAuth2 spec doesn’t define strict implementation standards, so developers have free reign to come up with some pretty wild implementations, or hack together a few libraries until it works. And that’s where the problem lies. There is no standard. Furthermore, social login is something that is normally built on top of OAuth2, and there’s no standard for that either. Some folks are trying to standardize social login with OpenID Connect (I like to think of this as “OAuth2-Strict”), but until then we will be facing issues like SpoofedMe because developers are not gods.
The SpoofedMe exploit is actually similar to this one, from a Google security advisory earlier this year:
“An attacker could forge an OpenID request that doesn’t ask for the user’s email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn’t notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account.” –Link
Thankfully, I read the spec and decided not to implement this gaping security hole in WP-OAuth to begin with. Properly identifying users to perform the account match was one of the biggest design challenges that I encountered because not only were there numerous docs and specs to work through, there were a lot of existing implementations that did it wrong. I had to start from scratch.