Should a brief explanation of this be added to the Threat Model and Security Considerations document? Or does anyone even agree that this can be a problem?
Regards, Andre DeMarre On Tue, Oct 4, 2011 at 11:32 AM, André DeMarre <andredema...@gmail.com> wrote: > 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
