Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

Eran Hammer <> Mon, 16 January 2012 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFB9D21F85C7 for <>; Mon, 16 Jan 2012 10:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.284
X-Spam-Status: No, score=-1.284 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OMD380Ww53db for <>; Mon, 16 Jan 2012 10:31:03 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B6BA721F8525 for <>; Mon, 16 Jan 2012 10:31:02 -0800 (PST)
Received: (qmail 14683 invoked from network); 16 Jan 2012 18:30:46 -0000
Received: from unknown (HELO ( by with SMTP; 16 Jan 2012 18:30:46 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([]) with mapi; Mon, 16 Jan 2012 11:30:24 -0700
From: Eran Hammer <>
To: OAuth WG <>
Date: Mon, 16 Jan 2012 11:30:21 -0700
Thread-Topic: [OAUTH-WG] Phishing with Client Application Name Spoofing
Thread-Index: AcyCxAdY8TnxswnOQImUO6LBmEocdxRuM5vg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jan 2012 18:31:04 -0000

Should this be added to the security model document? Is it already addressed there?


> -----Original Message-----
> From: [] 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 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" or "If you
> decide to allow this application, your browser will be directed to
>" 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