Subject: [OAUTH-WG] Why do we need the callback URL?

From: Luke Shepard <[email-masked]>
Date: Fri, 9 Apr 2010 11:34:02 -0700

(I'm looping the IETF mailing list into this discussion since I think it's useful) 

> Luke wrote:
>> I think the callback_url is superfluous in Web Callback Flow (D).
>> The session fixation attack can't happen because the verification_url will
>> only appear to the owner of the callback url - so I can't start a session,
>> wait for the user to finish, and then hijack it. And if the attacker is able
>> to control the callback URL (and the auth server sends the user there) then
>> they will be able to get an access token even in this system. So I don't see
>> the point.

Eran wrote:
> I had the same questions. In OAuth 1.0a, the callback is signed. The exploit
> here is if I start the auth process from my account, then grab the
> redirection to the auth server, change the callback, and trick you into
> following that link and approving access. When you do the verification code
> goes to my callback, and I fake the server call back to the client, causing
> my account to be linked to your information. If the server requires the
> callback, the client will fail because it will not provide the callback of
> the attacker.

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)

---

From: Brian Eaton <[email-masked]>
Date: Fri, 9 Apr 2010 12:07:22 -0700

> 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 boun…

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