In my proposal, the authorization will not proceed because victim doesn't have the cookie.So the victim will see the error that the session may be imposed on him by someone else. The request token will never get authorized.
Actually, I left out an important detail last night. When provider does the session check, it needs to drop the same cookie on its domain and check it later. Otherwise, this "session ok" callback can be played on victim's browser. Zhihong On Apr 24, 12:42 am, Jonathan Sergent <[email protected]> wrote: > > The victim is missing the cookie, the attacker has the valid cookie, > because it's the attacker's account at the consumer being linked, not > the victim's. > > If the attacker loads the callback URL before the victim does, the > token exchange will succeed. > > The scheme you describe is basic XSRF protection against the callback > URL, and consumers should be doing something like this anyway, to > prevent the inverse of the attack we've been worried about this week > (victim's account at consumer is linked to attacker's account at SP). > > > > > Zhihong --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
