How can the attacker use that flow? He can't set a callback in that URL since it can't be signed by him unless he has the consumer secrete. If there is no signiture, the provider ignores any parameters. It can lookup to see if a default callback has been registered and use that. If there is no default callback, the provider just displays the token for the user to manually enter.
On Sat, Apr 25, 2009 at 3:39 PM, Jonathan Sergent <[email protected]>wrote: > > On Sat, Apr 25, 2009 at 1:38 PM, Josh Roesslein <[email protected]> > wrote: > > As for the timing to apply this change, I think it would be worth it > taking > > the extra time to get it right. Most providers I think have already found > > quick fixes > > to block this session fixation attack. > > Really? The only "quick fix" I have seen is a scary warning message > on the approval page telling users not to use OAuth. > > > So I don't think we are in immediate > > danger, but I could be wrong. Just by adding callback URL signing and > > limiting request token swapping to one try should be enough to stop the > > session fixation. > > > > On Sat, Apr 25, 2009 at 3:35 PM, Josh Roesslein <[email protected]> > > wrote: > >> > >> Well this callback is short lived since it is swapped by the consumer > >> almost right away. So you don't have much time for a brute force attack > to > >> guess the callback URL. > >> Plus we can require that you only get once try to swap the callback for > an > >> access token. After that it is invalidated and no longer useful. > >> > >> On Sat, Apr 25, 2009 at 3:30 PM, Brian Eaton <[email protected]> wrote: > >>> > >>> On Sat, Apr 25, 2009 at 1:04 PM, Brian Eaton <[email protected]> > wrote: > >>> > On Sat, Apr 25, 2009 at 12:26 PM, Josh Roesslein < > [email protected]> > >>> > wrote: > >>> >> Thanks for posting that Brian. > >>> >> > >>> >> I'm leaning towards signed approval URLs. Seems the best way to go > >>> >> IMO. > >>> >> Seems to solve the issues and also helps simplify the OAuth flow. > >>> > > >>> > The major pain point of signed approval URLs is that we would lose > >>> > support for devices that either > >>> > a) can't open a web browser (because the signed approval URL is > really > >>> > long) > >>> > or > >>> > b) can't receive a callback URL (because the callback token is really > >>> > long). > >>> > > >>> > >>> Err, I should have pointed out that the other objection I've heard to > >>> signed approval URLs is that they are a major departure from the > >>> current protocol, and thus will slow down deployment of fixes. I'm > >>> not sure that's true, but it seems plausible. > >>> > >>> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
