true... must be in an after lunch stupor. O 2009/5/6 Manger, James H <[email protected]>
> I think it does solve the problem, Owen. > > > > The SP redirects B to the malicious callback – and remembers that this > malicious callback is associated with this request token & verifier. > > When the consumer asks for an access token the consumer will include the > original callback. The SP notices that the two callbacks are different and > rejects the access token request. > > > > *James Manger* > [email protected] > Identity and security team — Chief Technology Office — Telstra > ------------------------------ > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Owen Evans > *Sent:* Wednesday, 6 May 2009 11:09 AM > *To:* [email protected] > *Subject:* [oauth] Re: Confirm callback when getting access token > > > > 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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
