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

André DeMarre <> Mon, 16 January 2012 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4100521F86BE for <>; Mon, 16 Jan 2012 15:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kXyHx47C42kK for <>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5E88021F86AF for <>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
Received: by iaae16 with SMTP id e16so10194064iaa.31 for <>; Mon, 16 Jan 2012 15:20:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hfshg++KyPmJOT/JedZc1/AucjhNd9lVgK8hJNu0RfU=; b=tQeLjqgG9omM2xbQr7+rM2sQra546Gxr4uvA03yNU2lw7SADHMWSW+C+M+4wpVDqdB IY3TFXmADHOdxOXl+eHwwYiiQJdpaQkU9dTWI+GnNOm7OQnJdiLEeSdSJE/yFkOduwLm rAJUm5vsESVr+0WD7/9eu4UFfspnNqBEMZJF4=
MIME-Version: 1.0
Received: by with SMTP id p6mr11848268icc.44.1326756002210; Mon, 16 Jan 2012 15:20:02 -0800 (PST)
Received: by with HTTP; Mon, 16 Jan 2012 15:20:02 -0800 (PST)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <> <90C41DD21FB7C64BB94121FBBC2E723453A754C534@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Mon, 16 Jan 2012 15:20:02 -0800
Message-ID: <>
From: André DeMarre <>
To: Eran Hammer <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <>
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 23:20:05 -0000


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":

I'm happy to propose the text; it might be one or two days though.

Andre DeMarre

On Mon, Jan 16, 2012 at 10:30 AM, Eran Hammer <> wrote:
> 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