But I think people are missing the idea that the consumer can just use sessions and cookies to ensure that the browser which asked for the request token is the same as the one which is authenticating it. There's no need whatsoever for callback tokens, etc.
Also, it's important not to try too hard to micromanage the authorization process. If the malicious user creates a consumer which is going to do evil things, they don't need to 'trick' users into granting it access, they just need to convince a user that it's worth signing up. It's impossible for us to find out if a user has been 'tricked' into a page; if they authorize it, then they authorize it. All the SP can do is make sure that the users know what they're doing (i.e. via 'educating' them) and that their users know how to revoke access if they need to. That's one of the main selling points of OAuth; users *can* revoke access. So we should do what we can to stop malicious agents from exploiting the protocol itself, but it's not the job of the protocol to stop people from tricking each other. There are a couple of things I can think of which illustrate this perfectly. One of them is the phenomenon of 'shock websites' - would it be considered acceptable to implement protection from these within the HTTP standard itself? Also, most of us know what it's like to be constantly asked if you were the one that initiated a request: Microsoft did it with Windows Vista, and it's called User Account Control, and every time you run a program on Windows Vista you are asked if you just ran the program (which you clearly did). When we have, for the most part, a watertight protocol (after some of the changes recommended in this thread are implemented), there comes a limit past which the user annoyance increases exponentially as the actual security improvement achieved decreases exponentially. Regards, Zack On Apr 24, 5:55 pm, Allen Tom <a...@yahoo-inc.com> wrote: > Zachary Voase wrote: > > 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. > > The callback token helps to ensures that the Consumer will associate the > Access Token with the browser that passed it the callback token. The > attacker doesn't have the callback token. > > That being said, you are absolutely correct that if an attacker can > convince the victim to click on a link and authorize a token, not much > really can be done. The callback token helps protect innocent consumers > from associating the attacker's account with the victim's access token. > > Once this vulnerability is fixed, attackers will need to build their own > consumers, and trick victims into authorizing them. The overall user > experience for the victim is still mostly the same, however, the > attacker's consumer will be displayed on the SP's approval screen, > rather than the innocent consumer. We are, of course, assuming that > people read the approval screen. > > Allen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
