On Apr 24, 12:40 pm, Zachary Voase <disturb...@googlemail.com> wrote:
> OK, I definitely see what you mean with the callback nonce now and I
> completely agree that it plugs that last hole (where the attacker
> beats the user to the callback URL). Most of the messages preceding
> this one talked about callback nonces as these things that get
> generated with the request token that the user then has to enter, etc.
> I guess it was just an issue that we had different understandings of
> what a 'callback nonce' was. Thanks a lot for that.
>
Just to clarify a bit further -- my talk of authentication between A &
B and offering PIN as a possible approach is completely unrelated to
the callback nonce idea that was floated.
--peter
> Regards,
> Zack
>
> On Apr 24, 7:24 pm, Mike Malone <mjmal...@gmail.com> wrote:
>
> > > Personally, I don't think a callback nonce is going to do much at all
> > > to stop people from carrying out this attack. I've already said this
> > > twice in this thread, and I'll say it again:
>
> > Still not sure we're on the same page with the callback nonce suggestion.
> > Let me explain again (I'm going to address web flow only for simplicity):
>
> > Current vulnerability:
> > 1. Attacker initiates flow, gets redirect to SP.
> > 2. Attacker changes callback to a URL on a domain they control.
> > 3. Attacker tricks victim into clicking link with href=redirect w/ modified
> > callback.
> > 4. Victim authorizes the request token.
> > 5. Victim is redirected back to attacker's domain, gets some sort of error
> > page.
> > 6. Attacker goes to the _real_ callback, consumer exchanges request for
> > access token, attacker has access to victim's account.
>
> > Modified flow with callback signing but _no_ callback token:
> > 1. Attacker initiates flow, gets redirect to SP.
> > 2. Attacker can't change callback because the redirect URL is signed.
> > 3. Attacker tricks victim into clicking link with href=redirect w/ real
> > callback.
> > 4. Victim authorizes the request token.
> > 5. Victim is redirected back to the real callback, but there's a timing
> > vulnerability here - if the attacker can beat the victim to the callback URL
> > then the attacker can still be authorized to use the victim's account (more
> > on this, and on the single access token exchange restriction in a bit).
>
> > Modified flow with callback signing _and_ callback token:
> > 1. Attacker initiates flow, gets redirect to SP.
> > 2. Attacker can't change callback because the redirect URL is signed.
> > 3. Attacker tricks victim into clicking link with href=redirect w/ real
> > callback.
> > 4. Victim authorizes the request token.
> > 5. Victim is redirected back to the real callback, with a callback nonce on
> > the querystring parameter. The attacker doesn't know what the callback nonce
> > is, so they can't forge this request.
> > 6. The consumer site exchanges the request token for an access token. This
> > request must include the correct callback nonce from the previous step, else
> > it fails.
>
> > > If a malicious user can convince you to authorize an application,
> > > then (he/she/it) can almost certainly get you to put in a callback
> > > nonce as well. Submitting a form is still submitting a form, whatever
> > > extra bits one sticks on top of the process.
>
> > In the flow above, the user never enters the callback nonce manually. The
> > big concern with this particular vulnerability is that it defeats all of the
> > existing browser mechanisms for identifying a phishing attack because the
> > user is directed to the _real_ service provider to enter his/her
> > credentials.
>
> > Also, the attacker doesn't have to convince you to authorize _their_
> > application, they can have you authorize "random twitter client" to access
> > your twitter account, and then they can tweet through "random twitter
> > client" as you.
>
> > An attacker will always be able to do malicious things if they convince a
> > user to authorize their malicious client. The concern here is that the
> > attacker can get a legitimate client to give them access to another user's
> > account.
>
> > It interferes with the user experience, and it's a lot more trouble
>
> > > for very little potential benefit.
>
> > > Now, on the other hand there are some changes which have been
> > > suggested which will make a significant difference. One is placing
> > > restrictions on specification of the callback (whether by signing or
> > > specifying it when asking for the request token). Another is the once-
> > > only rule for exchanging request tokens for access tokens. These are
> > > real solutions which will plug up this security hole as much as
> > > possible. Can someone please cut the Gordian knot and make a decision?
>
> > I agree that the single access token exchange rule will do a lot to mitigate
> > this vulnerability, but I still don't think it's sufficient. I'd be happy
> > making the callback nonce optional, but without one there's still a
> > vulnerability.
>
> > In order to secure a token exchange with OAuth you need to use HTTPS
> > (otherwise there are a ton of MITM vulnerabilities). Problem is, even with
> > HTTPS and the single access token exchange rule an attacker on the same
> > network as the victim could guess with pretty high accuracy when to load the
> > callback URL (which it can easily determine by a bit of reconnaissance of
> > the consumer app). All they have to do is count the number of requests made
> > from the victim to the service provider, and once they've made that final
> > request to authorize the request token they can race the victim back to the
> > consumer callback URL. Callback nonce defeats this (as detailed above).
>
> > Maybe this is too obscure / theoretical an attack to matter, but it still
> > exists. And if we're trying to design a protocol suitable for banks and
> > other organizations that have real security needs then we need to really
> > address security issues.
>
> > Mike
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
