On Apr 29, 5:41 pm, Brian Eaton <[email protected]> wrote:
> On Wed, Apr 29, 2009 at 2:23 PM, John Kemp <[email protected]> wrote:
> > The oauth_verifier is to be linked by the SP to the request token and
> > the consumer key. So this ensures that the consumer is the same
> > consumer which applied for the request token on behalf of the user-
> > agent which is being led around all over the place in search of some
> > user data - correct?
>
> Yep. Sounds right.
In the session fixation attack, the attacker had to get to the
callback URL (which they may have forged, since it needn't have been
passed with the initial request for request token) before the victim.
With this fix:
1. They can no longer forge the callback URL
2. They would ALSO need the oauth_verifier, which there will have been
no opportunity to get since it was created AFTER authentication on SP.
Is that about right? If so, I'd say that's fixed. Your comparing it
to a CSRF defense is what made it click. I think I can back from my
stated need to prove u...@consumer == u...@sp, since we seem to have
demonstrated !(u...@consumer != u...@sp) well within expectation of
normal web security standards.
--peter
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
