Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)

Niv Steingarten <nivstein@gmail.com> Thu, 18 August 2011 12:48 UTC

Return-Path: <nivstein@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA321F8AB0 for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 05:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.566
X-Spam-Level:
X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+LrFYZj7jb3 for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 05:48:04 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79F4921F8A62 for <oauth@ietf.org>; Thu, 18 Aug 2011 05:48:04 -0700 (PDT)
Received: by vxi29 with SMTP id 29so2075768vxi.31 for <oauth@ietf.org>; Thu, 18 Aug 2011 05:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EEpGRDQBn3eqzhq8A8kRsKJAoDlV/e9UfvufZQ1mW7o=; b=OCNSD22ImtGNQekQNuVLfFiXxemczU3dzFgID3jlFRXUXyZnL1GxYggJmsx+iJpYJk fJ7PAesS1kScDlPJHRXT8bwtWp9m61mD1dcyj+Id/jGIbRj21J3TtuPUiMlqDshkLQlK j+FpSrenHDWLmGeQuyfjLX3lhJkEZrcLWdG1g=
Received: by 10.52.21.194 with SMTP id x2mr686722vde.389.1313671737153; Thu, 18 Aug 2011 05:48:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.107.170 with HTTP; Thu, 18 Aug 2011 05:48:37 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <b7df18688b7612cb85418ed587b80044@lodderstedt-online.de> <90C41DD21FB7C64BB94121FBBC2E72345029DFA960@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Niv Steingarten <nivstein@gmail.com>
Date: Thu, 18 Aug 2011 15:48:37 +0300
Message-ID: <CACEVmuoYO5NJrGNAHJsHennt_si+DTdA0QuLps8UBvMb=aLVoA@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Aug 2011 12:48:05 -0000

Here are two very simple examples. They are very naive ones, but get the
point across and I would not be suprised if they could be found in the
wild:

Say a client has its authorization endpoint at

  (1) http://www.domain.com/auth.php
	
A client requests access to protected resources by redirecting the
user-agent to:

  (2) http://www.domain.com/auth.php?response_type=code&client_id=1234&
      redirect_uri=SOMEURI&scope=SOMESCOPE

One possible design choice for the developer, if a bad one, is to have
the 'Allow' button point to:

  (3) http://www.domain.com/auth.php?[..previous query params..]&allow=1

In this case, a malicious client who knows the structure of this auth
flow, can simply skip (2) and redirect the user-agent to (3) in order
to gain access to the protected resources.

Another possible design choice for the developer (again, a very bad
one) would be to issue some kind of session cookie after (2) in order
to keep a state. Then, the 'Allow' button could possibly point to:

  (4) http://www.domain.com/allow.php

without any parameters (since the state is maintained by a cookie).

Here, an attacker could launch a request to (2) just to issue the state
cookie, and immediately redirect the user-agent to (4) in order to gain
access to the protected resources.

These are two very naive scenarios which can be averted using a nonce
for example (+ better design choices, for that matter).

In non-user-agent based clients, a client might also be able to actually
scrape the contents of the authorization HTML page, and simulate the
click programmatically. In this case a nonce would be useless, but a
CAPTCHA or a PIN code/password would solve the problem.

-- Niv



On Thu, Aug 18, 2011 at 08:58, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> I've read the thread leading to this, and the proposed text and I do not understand the attack. Can you provide a step-by-step scenario of how an attacker gains access?
>
> Also, it is unlikely that any major provider is going to require CAPCHA as part of the authorization flow. This is especially true in the case of using OAuth for login which has to be practically transparent (one click). I would hate to recommend a solution that no one is going to take seriously.
>
> I'm keeping this proposed text out until we resolve this questions.
>
> EHL
>
>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Torsten Lodderstedt
>> Sent: Friday, August 12, 2011 7:56 AM
>> To: oauth@ietf.org
>> Subject: [OAUTH-WG] Draft 20 last call comment (Resource Owner
>> Impersonation)
>>
>> Hi all,
>>
>> I think the impersonation issue as raised by Niv on the list should be covered
>> by the core spec. It directly aims at the trustworthiness of the user consent,
>> which in my opinion is one of the core principles of OAuth. I therefore
>> suggest to add a description to section 10.
>>
>> Please find below the text Niv and I prepared. In comparison to  Niv's original
>> proposal, it covers resource owner impersonation for all client categories.
>>
>> regards,
>> Torsten.
>>
>> proposed text:
>>
>> 10.<to be determined> Resource Owner Impersonation
>>
>> When a client requests access to protected resources, the authorization flow
>> normally involves the resource owner's explicit response to the access
>> request, either granting or denying access to the protected resources.
>>
>> A malicious client can exploit knowledge of the structure of this flow in order
>> to gain authorization without the resource owner's consent, by transmitting
>> the necessary requests programmatically, and simulating the flow against the
>> authorization server. An suthorization server will be vulnerable to this threat,
>> if it uses non-interactive authentication mechanisms or split the authorization
>> flow across multiple pages.
>>
>> It is RECOMMENDED that the authorization server takes measures to ensure
>> that the authorization flow cannot be simulated.
>> Attacks performed by scripts running within a trusted user-agent can be
>> detected by verifying the source of the request using HTTP referrer headers.
>> In order to prevent such an attack, the authorization server may force a user
>> interaction based on non-predictable input values as part of the user consent
>> approval.
>>
>> The authorization server could combine password authentication and user
>> consent in a single form, make use of CAPTCHAs or one-time secrets.
>>
>> Alternatively, the authorization server could notify the resource owner of
>> any approval by appropriate means, e.g. text message or e-Mail.
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>