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

André DeMarre <> Wed, 26 October 2011 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B45FC21F8B82 for <>; Wed, 26 Oct 2011 13:44:56 -0700 (PDT)
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 lN+0Pl4VAMG9 for <>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B7A1121F8B80 for <>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: by iabn5 with SMTP id n5so2721684iab.31 for <>; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
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=4zezIFM3Ujek1T/vMNDL1gnShuW1F65V9abtpZQhaIk=; b=DMVfcDNYhMBAuWcK2qUiUrcnY+yZx6za0EUCa4Kya/h9lG8T37B5JWHvaK6N1c5NYl jh6yrUpmnJyJ2aq5PxC2dGnaUxWXmmbsAZmMJRgYxIRZqudIV+HIxR9emIE3OjWU/uv9 7IRVssMP+TDxPDncZeHbtyVHk74ElzNo0tef4=
MIME-Version: 1.0
Received: by with SMTP id o2mr53244669icz.15.1319661895430; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
Received: by with HTTP; Wed, 26 Oct 2011 13:44:55 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 26 Oct 2011 13:44:55 -0700
Message-ID: <>
From: André DeMarre <>
To: OAuth WG <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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, 26 Oct 2011 20:44:56 -0000

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?

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