James, you made the best argument (in my view) of why we should stick with the existing proposal, namely that the easiest way to preserve statelessness is to implement a measure that results in XSRF protection side effects.
On Tue, May 5, 2009 at 6:21 PM, Owen Evans <owenmcev...@gmail.com> wrote: > true... must be in an after lunch stupor. > O > > 2009/5/6 Manger, James H <james.h.man...@team.telstra.com> >> >> 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 >> james.h.man...@team.telstra.com >> Identity and security team — Chief Technology Office — Telstra >> >> ________________________________ >> >> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of >> Owen Evans >> Sent: Wednesday, 6 May 2009 11:09 AM >> To: oauth@googlegroups.com >> 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 >> > > > > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
