When you're logged in to a Stack Exchange account, it's possible to add and remove logins (associated OpenID/OAuth accounts) without performing any form of reauthentication.
This is not a full vulnerability in itself, but it provides an extremely easy way for an attacker who's found a temporary XSS vulnerability to turn that into a permanent account hijack. An XSS exploit on its own may only provide a minute of indirect access to a user's account. But with this login configuration, the attacker could use that minute to automatically:
Add a new attacker-controlled login to the account. For example:
- The XSS JavaScript would generate a random identifier, and use that to construct a login URL of the form
http://hacker.example/openid/1234567. - The
hacker.exampleserver would automatically authenticate the first OpenID login request made with a given identifier, allowing it to be added to the account without user interaction. All subsequent login attempts would be automatically rejected for the user. - The
hacker.exampleserver would notify the operator with the account name and the generated identifier, and would allow them to login to it.
- The XSS JavaScript would generate a random identifier, and use that to construct a login URL of the form
Remove all existing logins from the account.
Log the user out of their account, with no way to get back in.
If this exploit were used to hijack moderator and staff accounts it could makes it more difficult to quickly respond to an attack, creating a greater opportunity for extended abuse.
This is a broader instance of the same fundamental vulnerability which was previously-reported as Can we fix the security hole in the password change dialog and ask for a user's current password?. That instance is a little more straightforward to fix: just ask for the password again when changing it. However, safe reauthentication with OpenID/OAuth logins is more complicated. Most users' OpenID providers will be configured to automatically re-authenticate upon request, so there would be minimal security gain from requesting that.
Instead or as well, my suggestion is that for users that have a verified email address, require an emailed confirmation link to be clicked before committing any login changes.
I'm not a real security expert, but I've just found that fellow Stack Overflow user Troy Hunt, who is, previously described this vulnerability in his 2012 blog post Is Stack Overflow Secure? Kind of...:
If an attacker can add additional login accounts then they can create a persistent mechanism to get back into that Stack Overflow account at any time without needing to hijack the session. Now of course the victim can always go into their account settings and identify the presence of the new login, but it’s a question of how much damage is done before then.
How would an attacker mitigate the risk of having their newly added account removed? Just remove the victim’s original account(s) instead.
[...]
Finally, this is also a lesson for those considering using third party authentication providers. Yes, it’s great that you can farm off this work to someone who has a solid implementation, but you still have responsibility for securing the authenticated session on your site. If you choose not to, be aware of the risks because certainly we’ve seen them exploited before.
