Andre You are right that the threat model does not cover this kind of issue related to client registration. Client registration is considered to be out of scope in the oauth spec but it is worth drawing developers attention to this. I can add a threat entitled something like "Client Registration of phishing clients". It kind of reminds me of the issues android market place has seen recently with malware apps due to no vetting of those apps.
It is touched upon in the oauth 2 rfc: http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2 Regards Mark On 3 Nov 2011 17:09:39, "Andre DeMarre" wrote: You are right that they are similar, but there is a difference, and only one of the six countermeasures is relevant to the threat I described. http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4 seems to be about an attack where the malicious client impersonates a different (valid) client that is registered with the authorization server. In other words, the valid client is registered as client_id 123, and the malicious client does not have its own client_id but tries to pose as client 123. This corresponds to http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-10.2. In the threat I described, there is no valid client. The malicious client is properly registered with the authorization server and has its own client_id and client credentials. It can authenticate with the authorization server without trying to pose as a different client. As an attacker you might reason, "Why would I try to impersonate a valid client for which I don't know the client credentials and can't pass the redirect URI test, when I can just register my own client with my own redirect URI and be given my own credentials?" Imagine the attacker wants to impersonate Google with a popular web service called Foobar. The attacker registers his application with Foobar's auth server. It does not matter if the real Google has registered an authentic app with Foobar. The attacker has no reason to be interested in stealing or guessing client credentials when he can simply register his own app and call it "Google". The information the auth server shows to end users when asking them to grant authorization becomes very important. Regards,Andre DeMarre On Wed, Nov 2, 2011 at 2:27 PM, Torsten Lodderstedt <torsten at lodderstedt.net> wrote: > Hi Andre, > > how do you think differs the threat you descibed from > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4 ? > > regards, > Torsten. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
