Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration

Niv Steingarten <nivstein@gmail.com> Mon, 25 July 2011 23:41 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 CA0E911E80D7 for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 16:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.5
X-Spam-Level:
X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le1vNPdS9kvv for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 16:40:59 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC26311E80B1 for <oauth@ietf.org>; Mon, 25 Jul 2011 16:40:59 -0700 (PDT)
Received: by vws12 with SMTP id 12so4178231vws.31 for <oauth@ietf.org>; Mon, 25 Jul 2011 16:40:59 -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=FEbpPZnG2FILMdbLsvz1u8cm6Ef58VHQ7vXIG5fgBZk=; b=uLEpInMqod7UiDdIxhqyg+kxbf/5AM0Z/CqAdY+7kitnR0MBcVob1unZKYGBiChSUl iTpvPPrWy9NGv4Yn8hCjLFlL2nEbGXxqicsfOPxHTVxdftzDolx5fPQv2XH1lq2BfT1+ ABkyIw5kw/Pggi/xogHWC5Q5dtknfgEco3+Ls=
Received: by 10.52.173.235 with SMTP id bn11mr5233573vdc.19.1311637259117; Mon, 25 Jul 2011 16:40:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.107.99 with HTTP; Mon, 25 Jul 2011 16:40:39 -0700 (PDT)
In-Reply-To: <4E2DF7D5.8090701@lodderstedt.net>
References: <CACEVmuoodRGS45zHmnTWX04uGhgTCLgSddLbPPd2qgoudrq31A@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723450245F58E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CACEVmurNP=G9c06bS4ftk+bKgNuFw+VVna132numsyPSBjVP+A@mail.gmail.com> <4E2DF7D5.8090701@lodderstedt.net>
From: Niv Steingarten <nivstein@gmail.com>
Date: Tue, 26 Jul 2011 02:40:39 +0300
Message-ID: <CACEVmurmBA9Ewb+SiSPGmEmQQtKiTTVmWR2D3kV1NH7Qv_HOuw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
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: Mon, 25 Jul 2011 23:41:00 -0000

Yes, I believe the vast majority of user-agents would block this kind
of request if it originated from a JavaScript XMLHttpRequest or such.
However, there are still scenarios in which a user-agent based client
could manipulate this vulnerability.

For example, the client could launch the GET request to the
authorization server via an <img> HTML tag, taking the form of a CSRF.
Since it's a blind attack, the client would likely not receive the
contents of the web-page. However, this request is still necessary
from the client since it has the side-effect of creating an access
token (or other temporary token) on the authorization server. Since it
is highly likely that a malicious client has a priori knowledge of the
structure of the authorization page and form, it does not need the
response in order to advance to the next step, and can simply send the
fake request to 'Allow' itself to access the resource owner's
resources.

I believe this attack could be made very hard by either including a
CAPTCHA, as you suggested, or including some kind of token or nonce in
the submission of the form (which would still not prevent the attack
if the authorization server doesn't enforce same origin policy).

Niv



On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt
<torsten@lodderstedt.net> wrote:
>
> Hi Niv,
>
> thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)?
>
> Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA).
>
> regards,
> Torsten.
>
> Am 25.07.2011 18:27, schrieb Niv Steingarten:
>
> Forwarded as per Eran's request.
> A couple of corrections to my original email:
> 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy).
> 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request.
> Thank you,
> Niv
>
>
> ---------- Forwarded message ----------
> From: Eran Hammer-Lahav <eran@hueniverse.com>
> Date: Tue, Jul 26, 2011 at 01:21
> Subject: RE: Several typos in -20 and a possible security consideration
> To: Niv Steingarten <nivstein@gmail.com>
>
>
> Please forward this message to the oauth list at oauth@ieft.org.
>
>
>
> Thanks,
>
>
>
> EHL
>
>
>
> From: Niv Steingarten [mailto:nivstein@gmail.com]
> Sent: Monday, July 25, 2011 2:52 PM
> To: draft-ietf-oauth-v2@tools.ietf.org
> Subject: Several typos in -20 and a possible security consideration
>
>
>
> Hello,
>
>
>
> I've noticed a couple of typos in -20:
>
>
>
> Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word "and", and the third bullet should end with a full-stop.
>
> Section 10.2 (first paragraph): "...keep is client credentials confidential" should be "...keep *its* client credentials confidential".
>
>
>
> Regarding the security consideration --
>
>
>
> I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation.
>
> For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header.
>
>
>
> Thanks for your time and for the fantastic work on OAuth,
>
>
>
> --
>
> Niv Steingarten
>
>
>
> T: 
>
> E:  nivstein@gmail.com
>
> W: http://nivstein.com
>
>
>
>
> --
> Niv Steingarten
> T: 
> E:  nivstein@gmail.com
> W: http://nivstein.com
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth