Thanks for the feedback. On Wed, Apr 29, 2009 at 11:35 AM, John Kemp <[email protected]> wrote: > Nit: this checklist would be a bit less confusing if the order for > each item remained constant (item 2 of the comparison has 'approval' > and 'callback' in a different order than the other items).
Fixed. > i) It seems (but is unstated) that the consumer must have a notion of > who the 'user' is (prior to issuing the initial request to the SP) in > order to generate a _per-user_ callback URL (ie. callback URLs would > then be required to be per-user?), and must then validate in step 3 > that the user which started the process is the same one which the > consumer is now redirecting to the SP? Yep, OAuth consumers need to XSRF protect the callback URL. Eran mentions this in his blog post [1], search for "even if an application:". I don't think consumers need an actual user login, though it doesn't hurt. Any sort of transient session state to identify the client is OK. One risk here is cross-site cooking [2]. I don't think this is something that the protocol can fix; individual consumer apps are not excused from following good web application security practices. XSS on the consumer is still bad, no matter how much magic OAuth security dust you sprinkle. =) This also impacts desktop apps with callback URLs: they should not read the request token and token secret off the callback URL! Those have to be stored on the client somewhere. It seems possible to use the oauth_token on the callback URL as the XSRF prevention token, so long as the oauth token is bound to the browser session. > If that check fails, then should the protocol stop there? It definitely has to stop. Not sure of the best practice for consumers here. Maybe prompt the user for confirmation before allowing the protocol to continue, maybe ask them to start the whole OAuth dance again. > ii) Is the intent of the oauth_verifier to prevent the possibility of > a similar redirect break between acquiring the authorized request > token and getting the access token? You lost me on this one, can you rephrase? [1] http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html#more [2] http://www.securiteam.com/securityreviews/5EP0L2KHFG.html --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
