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.
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 -~----------~----~----~----~------~----~------~--~---
