Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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 th
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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-arch ive/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 " is requesting permission > to..." > > >> > > >> Imagine someone registers a client application with an OAuth se
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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
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
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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 tors...@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. Am 26.10.2011 22:44, schrieb André DeMarre: 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é DeMarreandredema...@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
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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. Am 26.10.2011 22:44, schrieb André DeMarre: 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é DeMarreandredema...@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
Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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
[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
