Doesn't really solve the problem: (malicious) User A gets the "Authorisation URL" from an application that has received a request token. User A replaces call-back parameter with malicious or spoof site instead of original call-back User A tricks User B (Innocent) into logging into SP with incorrect call-back parameter. User B is sent to malicious site which save the verification code. User A gets verification code from malicious site and uses it to redirect to original consumer application User A now has access to User B's resources.
O 2009/5/6 Manger, James H <[email protected]> > I would like to suggest a slightly different solution for the OAuth > session fixation bug. > > > > The Consumer App includes the Callback URI when obtaining an Access Token, > instead of including the Callback URI when obtaining a Request Token. > > > > The Service Provider checks that the Callback URI in the request for an > Access Token matches the Callback URI to which the authorizing user was > redirected. > > > > The significant advantage of this approach is that the Consumer App knows > the Request Token and Secret before they specify the Callback URI so they > can encode state into the callback and operate in a stateless manner – which > is important for scalability. > > > > An advantage of this approach for the Service Provider is that there is no > extra state that has to be maintained between the Request Token and > Authorization steps so the SP’s Request Token format should not need to > change to maintain stateless operation. > > > > I believe Consumer Apps can operate in a stateless manner with OAuth Core > 1.0 so it would be a significant disadvantage to break this ability in a > security fix. My guess is that it would require very substantial changes to > a Consumer App’s architecture if it had to switch from a stateless to a > statefull mode to support a security fix. > > > > The Callback URI still appears in the authorization step, but changing it > does not help an attacker since that would cause the subsequent request to > obtain an Access Token to fail. > > > > > > > > 6.1.1. Consumer obtains a Request Token – UNCHANGED from 1.0 > > > > 6.1.2. Service Provider issues an unauthorized Request Token – UNCHANGED > from 1.0 > > > > 6.2.1. Consumer directs the User to the Service Provider – UNCHANGED from > 1.0 > > > > 6.2.2. Service Provider authenticated the User and obtains consent – change > warning text in some situations > > > > 6.2.3. Service Provider directs the user back to the Consumer – insert > “verifier” into callback, or display “verifier” > > > > 6.3.1. Consumer requests an Access Token – CHANGED to include Callback URI > > > > 6.3.2. Service Provider grants an Access Token – UNCHANGED from 1.0 at the > protocol layer, but the SP performs an extra check (that the Callback URI > matches) before responding > > > > > > > > The OAuth wiki (http://wiki.oauth.net/OAuth-Session-Fixation-Advisory) > compares proposed solutions with 10 questions. 9 answers for this proposal > (callback with access token request) are the same as the “signed callback > URLs” (callback with request token request) solution. The only difference is > supporting a smooth upgrade path from 1.0 to the fixed protocol. This > proposal can certainly support a smooth upgrade path, but it cannot use the > presence of oauth_callback when obtaining a Request Token to indicate > support for the new version. Any other indication would do. A different > Request Token URI is one option. > > > > > > > > *James Manger* > > [email protected] > > Identity and security team — Chief Technology Office — Telstra > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
