On Fri, Apr 9, 2010 at 11:34 AM, Luke Shepard <[email protected]> wrote: > Let me see if I understand this attack. Let's say Evil Eve goes to > Example.com. Example.com redirects her to: > > https://facebook.com/oauth/authorize?client_id=XXX&type=web_callback_access_request&callback=http://example.com/oauthcallback > > Then, she changes the callback and gives this link to Alice: > > https://facebook.com/oauth/authorize?client_id=XXX&type=web_callback_access_request&callback=http://evil.com/oauthcallback > > Alice approves Example.com and clicks ok. Then she is directed to: > > http://evil.com/oauthcallback&code=vvvvv > > Now, Eve has the verification code, and she wants an access token. She needs > to make a request like this: > > https://facebook.com/oauth/authorize?client_id=XXX&type=web_callback_token_request&code=vvvvv&client_secret=I_DONT_HAVE_IT > > But she doesn't have the client secret - it is still sitting on example.com > servers. So she still can't get an access token. And even if she does require > the callback, the code "vvvvv" will be bound to the "evil.com" domain anyway > (presuming the auth server doesn't kill the redirect because of > pre-registered callback anyway)
There is a relay attack. 1) facebook.com redirects the user to evil.com 2) evil.com grabs the verification code. 3) evil.com sends the verification code to http://example.com/oauthcallback?oauth_verifier=<verifier> 4) example.com exchanges the verifier for a refresh token and access token. 5) example.com associates the access with Eve's account instead of the good guys. This is covered in the security considerations I wrote up for the OAuth WRAP Web Delegation Profile: http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations. Cheers, Brian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
