Eran, Yes; I think a section should be added to the security model doc.
On 2011-12-16 Mark Mcgloin agreed and suggested we call it "Client Registration of phishing clients": http://www.ietf.org/mail-archive/web/oauth/current/msg08061.html I'm happy to propose the text; it might be one or two days though. Regards, Andre DeMarre On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer <e...@hueniverse.com> wrote: > Should this be added to the security model document? Is it already addressed > there? > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of André DeMarre >> Sent: Tuesday, October 04, 2011 11:33 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Phishing with Client Application Name Spoofing >> >> I've not seen this particular variant of phishing and client impersonation >> discussed. A cursory search revealed that most of the related discussion >> centers around either (a) client impersonation with stolen client credentials >> or (b) phishing by malicious clients directing resource owners to spoofed >> authorization servers. This is different. >> >> This attack exploits the trust a resource owner has for an OAuth >> authorization server so as to lend repute to a malicious client pretending to >> be from a trustworthy source. This is not necessarily a direct vulnerability >> of >> OAuth; rather, it shows that authorization servers have a responsibility >> regarding client application names and how they present resource owners >> with the option to allow or deny authorization. >> >> A key to this exploit is the process of client registration with the >> authorization >> server. A malicious client developer registers his client application with a >> name that appears to represent a legitimate organization which resource >> owners are likely to trust. Resource owners at the authorization endpoint >> may be misled into granting authorization when they see the authorization >> server asserting "<some trustworthy name> is requesting permission to..." >> >> Imagine someone registers a client application with an OAuth service, let's >> call it Foobar, and he names his client app "Google, Inc.". The Foobar >> authorization server will engage the user with "Google, Inc. is requesting >> permission to do the following." The resource owner might reason, "I see >> that I'm legitimately on the https://www.foobar.com site, and Foobar is >> telling me that Google wants permission. I trust Foobar and Google, so I'll >> click Allow." >> >> To make the masquerade act even more convincing, many of the most >> popular OAuth services allow app developers to upload images which could >> be official logos of the organizations they are posing as. Often app >> developers can supply arbitrary, unconfirmed URIs which are shown to the >> resource owner as the app's website, even if the domain does not match the >> redirect URI. Some OAuth services blindly entrust client apps to customize >> the authorization page in other ways. >> >> This is hard to defend against. Authorization server administrators could >> police client names, but that approach gives them a burden similar to >> certificate authorities to verify organizations before issuing certificates. >> Very >> expensive. >> >> A much simpler solution is for authorization servers to be careful with their >> wording and educate resource owners about the need for discretion when >> granting authority. Foobar's message above could be >> changed: "An application calling itself Google, Inc. is requesting >> permission to >> do the following" later adding, "Only allow this request if you are sure of >> the >> application's source." Such wording is less likely to give the impression >> that >> the resource server is vouching for the application's identity. >> >> Authorization servers would also do well to show the resource owner >> additional information about the client application to help them make >> informed decisions. For example, it could display all or part of the app's >> redirect URI, saying, "The application is operating on example.com" or "If >> you >> decide to allow this application, your browser will be directed to >> http://www.example.com/."; Further, if the client app's redirect URI uses TLS >> (something authorization servers might choose to mandate), then auth >> servers can verify the certificate and show the certified organization name >> to >> resource owners. >> >> This attack is possible with OAuth 1, but OAuth 2 makes successful >> exploitation easier. OAuth 1 required the client to obtain temporary >> credentials (aka access tokens) before sending resource owners to the >> authorization endpoint. Now with OAuth 2, this attack does not require >> resource owners to interact with the client application before visiting the >> authorization server. The malicious client developer only needs to distribute >> links around the web to the authorization server's authorization endpoint. If >> the HTTP service is a social platform, the client app might distribute links >> using >> resource owners' accounts with the access tokens it has acquired, becoming >> a sort of worm. Continuing the Google/Foobar example above, it might use >> anchor text such as "I used Google Plus to synchronize with my Foobar >> account." Moreover, if the app's redirect URI bounces the resource owner >> back to the HTTP service after acquiring an authorization code, the victim >> will >> never see a page rendered at the insidious app's domain. >> >> This is especially dangerous because the public is not trained to defend >> against it. Savvy users are (arguably) getting better at protecting >> themselves >> from traditional phishing by verifying the domain in the address bar, and >> perhaps checking TLS certificates, but such defenses are irrelevent here. >> Resource owners now need to verify not only that they are on the legitimate >> authorization server, but to consider the trustworthyness of the link that >> referred them there. >> >> I'm not sure what can or should be done, but I think it's important for >> authorization server implementers to be aware of this attack. If >> administrators are not able to authenticate client organizations, then they >> are shifting this burden to resource owners. They should do all they can to >> educate resource owners and help them make informed decisions before >> granting authorization. >> >> Regards, >> Andre DeMarre >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
