On Thu, Apr 30, 2009 at 5:50 PM, Breno de Medeiros <[email protected]> wrote: > > I do not see how an empty value is an improvement from a non-valid > URI. It may not cause problems, but we don't know that. Let's play > safe and if people are unhappy with 'oob', then say 'outofband' or > something. > > Not included in request token request seems not an option for clients > that expect a verifier, if we expect SPs will have a period of > handling both flows.
I maintain that whether a consumer is able to receive callbacks is something that should happen when the consumer key is issued, not when the request token is issued. To reiterate: 1. Attacker obtains consumer key and secret from the distributed consumer code. 2. Attacker obtains request token with callback pointing to a site that they control. 3. Attacker sends their target the authorization URL with the request token. 4. Target authorizes the application, and because a callback URL is present, no additional warnings are displayed to the user (since the verification code will be used to ensure that endpoint receiving the authorization was the one that initiated the flow). 5. Target is redirected to the attacker's site, verification code in hand. 6. Attacker is able to exchange the request token for a valid access token with rights to the target's account on the service provider. The only way to avoid this attack is to know in advance of issuing a request token that a consumer is a desktop application. In such cases, the user should be given a strict warning by the service provider about the conditions under which they should approve the application. In general, I disagree that applications can't handle callbacks. There is extensive support for custom protocol handlers in all major operating systems, and we should be encouraging application developers to think carefully about how their applications interact with the web. In cases where callbacks are not supported, there should never be the option to flip back and forth. Either the application supports callbacks, or it doesn't, end of story. b. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
