two days can last for a very long time ;-) I will add this threat to the list to be covered by our new security draft.
> Am 10.05.2017 um 23:15 schrieb André DeMarre <andredema...@gmail.com>: > > I see there is a new security considerations document being drafted. There is > an old issue that I've recently been reminded of. > > Should text about phishing conducted through the authorization dialog be > added to the new security document? This kind of attack made headlines last > week with a widespread Gmail / Google Docs phishing worm > (https://security.googleblog.com/2017/05/protecting-you-against-phishing.html). > > Five years ago, I was encouraged to propose text about this for the Threat > Model and Security Considerations document, but I never did; sorry. Original > thread in the mail archive: > https://www.ietf.org/mail-archive/web/oauth/current/msg07625.html > > This concerns both authorization dialog design and client registration, and > as far as I know it's not really covered in any published documents. I'm not > entirely sure what mitigations should be recommended, but I think > authorization server implementers need to be more cognizant of this attack. > > Regards, > Andre DeMarre > >> On Tue, Jan 17, 2012 at 4:06 AM, Mark Mcgloin <mark.mcgl...@ie.ibm.com> >> wrote: >> Andre >> >> Please feel free to propose text, perhaps with a better title than I >> suggested. During our discussion on section 4.1.4 (End-user credentials >> phished using compromised or embedded browser), we have decided on the >> countermeasure below, albeit for a different threat - phishing client as >> opposed to client name spoofing. Your's can be a variant of this with >> different validation recommendations. >> >> >> 2. Client applications could be validated prior to publication in an >> application market for users to access. That validation is out of scope for >> OAuth but could include validating that the client application handles user >> authentication in an appropriate way >> >> >> Regards >> Mark >> >> André DeMarre <andredema...@gmail.com> wrote on 16/01/2012 23:20:02: >> >> > >> > To: >> > >> > Eran Hammer <e...@hueniverse.com> 16/01/2012 23:22 >> > >> >> > >> > Re: [OAUTH-WG] Phishing with Client Application Name Spoofing >> > >> > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
