Account hijacking when SOCIAL_AUTH_ASSOCIATE_BY_MAIL=True #356

Closed
pennersr opened this Issue Jun 1, 2012 · 3 comments

Comments

Projects
None yet
3 participants
@pennersr

pennersr commented Jun 1, 2012

Consider the following scenario:

  • There is a user with e-mail address john@doe.com whose account I would like to hijack
  • I'll go over to a 3rd party OpenID provider and add john@doe.com as my e-mail address. Of course, given that I do not own the e-mail address I am unable to verify ownership of the e-mail address.
  • Yet, several OpenID providers pass along this unverified e-mail address during the OpenID handshake (e.g. largest Dutch OpenID provider Hyves.nl facilitates this).
  • django-social-auth will incorrectly hook up my OpenID to John's account, based on the fact that it assumes my e-mail address is john@doe.com
@omab

This comment has been minimized.

Show comment
Hide comment
@omab

omab Jun 1, 2012

Owner

DSA could narrow this issue by sending some confirmation email, but users would be annoyed with so many confirmations, the pipeline won't be hard to implement and those willing to ignore it can disable it easily. Besides that, I don't think another solution could be implemented to avoid that situation, a simpler approach would be to just add a comment to the docs explaining the risk of this setting.

This is a good problem to get solve, so I might take some time to implement the pipeline entry to send confirmations.

Owner

omab commented Jun 1, 2012

DSA could narrow this issue by sending some confirmation email, but users would be annoyed with so many confirmations, the pipeline won't be hard to implement and those willing to ignore it can disable it easily. Besides that, I don't think another solution could be implemented to avoid that situation, a simpler approach would be to just add a comment to the docs explaining the risk of this setting.

This is a good problem to get solve, so I might take some time to implement the pipeline entry to send confirmations.

@pennersr

This comment has been minimized.

Show comment
Hide comment
@pennersr

pennersr Jun 2, 2012

Associating by e-mail seems to be the default. This opens up a major security vulnerability in many existing DSA deployments that have OpenID enabled. Therefore, I feel you should at least change the defaults, perhaps even (temporarily) disable this feature completely.

pennersr commented Jun 2, 2012

Associating by e-mail seems to be the default. This opens up a major security vulnerability in many existing DSA deployments that have OpenID enabled. Therefore, I feel you should at least change the defaults, perhaps even (temporarily) disable this feature completely.

@omab omab closed this in 9cd3579 Jul 9, 2012

@brycenesbitt

This comment has been minimized.

Show comment
Hide comment
@brycenesbitt

brycenesbitt Nov 22, 2013

There's another way in also:

If someone hacks an account at any of the social auth providers, they can then associate to unprotected django-socialauth sites, even if the legitimate user never set up such a linkage.

There's another way in also:

If someone hacks an account at any of the social auth providers, they can then associate to unprotected django-socialauth sites, even if the legitimate user never set up such a linkage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment