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