Hi Mike,
I have a proof of concept I think might be similar to this. It
works like so:
1. When the consumer gets the request_token the provide the callback
URL.
» Note this is server-to-server communication, unavailable to the
user.
2. The user is redirected to the service provider to authorize the
application.
3. Once authorized the user is redirected the the callback URL with an
additional callback_token parameter.
4. When requesting the access_token the consumer provides the
callback_token.
» If the request_token has a callback but the access_token request
does not have the callback_token access is denied and the request
token is invalidated.
» If the request_token had no callback but the access_token request
does access is denied and the request token is invalidated.
» If the callback_token does not match the one on record access is
denied and the request token is invalidated.
By sending the callback in the server-to-server communication it
is not available to the user/attacker. This is also a signed request
so man-in-the-middle changes to the oauth_callback will be caught by
the signature. The final step of checking the callback_token prevents
other man-in-the-middle style attacks after the user has been returned
to the consumer app. Does this sound like what you're suggesting?
Thanks;
– Matt Sanford / @mzsanford
Twitter API Developer
On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:
> How bout this...
>
> Instead of the provider signing the callback URL, the consumer signs
> the redirect to the SP using its consumer and request tokens. This
> will prevent an attacker from changing the callback URL, but still
> allow the consumer to specify any redirect URL it wants (provided
> the SP accepts any callback URL).
>
> This reduces the threat to what Eran called a "timing attack" in his
> blog post. There's still a possibility that the attacker could beat
> the victim back to the callback after the request token is
> authorized. To mitigate this, the provider could generate a callback
> nonce that must be provided during the request/access token
> exchange. This nonce would be appended as a querystring param to the
> callback URL.
>
> I think these two changes eliminate the threat with the smallest
> change to the spec, and without requiring either side to maintain a
> lot of extra state across steps. The SP needs to maintain the
> callback nonce, but it can be stored and expired with the request
> token.
>
> The drawback is that the manual auth process would require the user
> to enter two numbers at the consumer after authorizing a token: the
> request token key and the callback nonce.
>
> Mike
>
> On Thu, Apr 23, 2009 at 9:25 AM, Shan <[email protected]> wrote:
>
> I have a simple idea to propose not as a solution, but hopefully to
> give someone an idea toward a true solution:
>
> What if the callback URL is signed on the provider's end using the
> consumer's secret key? The drawback is it puts the burden on the
> consumer to close the security hole by checking the signature, and as
> such the provider has no way of knowing if an application is secure or
> not.
>
> Shan
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
