Mike, Thanks for clearing up our terminology around the callback nounce.
On Apr 24, 11:24 am, Mike Malone <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
