Should this be added to the security model document? Is it already addressed there?
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
