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

Torsten Lodderstedt <> Wed, 02 November 2011 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 798C91F0CB4 for <>; Wed, 2 Nov 2011 14:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kOawBzfqonSk for <>; Wed, 2 Nov 2011 14:27:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5833C1F0C59 for <>; Wed, 2 Nov 2011 14:27:13 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1RLiKz-0001zd-0a; Wed, 02 Nov 2011 22:27:09 +0100
Message-ID: <>
Date: Wed, 02 Nov 2011 22:27:07 +0100
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: André DeMarre <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
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: Wed, 02 Nov 2011 21:27:14 -0000

Hi Andre,

how do you think differs the threat you descibed from

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é DeMarre<>  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
>> 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