Re: [OAUTH-WG] Same Origin Method Execution (SOME)

Nat Sakimura <sakimura@gmail.com> Mon, 29 June 2015 15:22 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1261A1B1D for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 08:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul-afVMdfaAZ for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 08:22:29 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34E21A1ADA for <oauth@ietf.org>; Mon, 29 Jun 2015 08:22:28 -0700 (PDT)
Received: by oiax193 with SMTP id x193so120359957oia.2 for <oauth@ietf.org>; Mon, 29 Jun 2015 08:22:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7dR2i2hbXz73cZczitw6JOJCJjH4HnjjohFUi3WIv8=; b=Wh3/Ae3qvYtieZVCmmM+u64tHhFVkcmN08U6g/03kp5ArL1v5QNDxi+IELtKu49Bbz gLgdhtne1X0YRASvxAh9KxmsLXSu1Jk6bw+aNsgluEDyzyLxL3XLgCtLSjAGBXVINeMP A0MO+ipLFFbhtnmofn7wDLIg4XQYm/HXH3S+Ks0MIcqNPGZwc7oQXqzbuH5mnBXgU6ES s0iZXzk9AT9qm6mtY92EBU4bYqD5CP+ml0bvzeIgmkJzr45fkmHoU4hVq0/d2AGDVD1Z bYBVwkXKhkuGl9q6Dh3hwt588+CZCrV7MAZA9Ed0ThmshflkwarOZm9d13t0esR5tuh4 DVAw==
MIME-Version: 1.0
X-Received: by 10.182.186.2 with SMTP id fg2mr12606522obc.35.1435591348262; Mon, 29 Jun 2015 08:22:28 -0700 (PDT)
Received: by 10.60.164.97 with HTTP; Mon, 29 Jun 2015 08:22:28 -0700 (PDT)
In-Reply-To: <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com>
References: <B1C45938-9B95-4059-8235-0745216DFF60@adobe.com> <DACC2E36-E0E1-47C9-BC8F-CDEB1C13939D@ve7jtb.com> <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com>
Date: Tue, 30 Jun 2015 00:22:28 +0900
Message-ID: <CABzCy2AA+MbxS-_GX3m-cYL9GVdOYjLhkEYGVb4q_8wbz7wUjQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Antonio Sanso <asanso@adobe.com>
Content-Type: multipart/alternative; boundary=089e0141a71a5b1c8c0519a9a848
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/qtNTTaUoeFdkbcG-RionqX9bkFM>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Same Origin Method Execution (SOME)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 29 Jun 2015 15:22:31 -0000

Year, from my skimming of the paper, it requires a page that executes
arbitrary callback function given as a parameter.
It is absolutely stupid to do it, but apparently there are such pages.
Prime candidate happens to be OAuth Redirection Endpoint.
By itself, it probably will not do much harm because you cannot do much
things in that window itself,
but if the window is a pop-up and keeps a parent context, it will
essentially be able to
remote control the parent window to do much more harm.

So, it is not OAuth problem per se.

However, it may be worthwhile to tell the developers to make sure that
redirection endpoint
accepts only valid oauth payload, and do not execute anything in the
parameter.

Nat

2015-06-25 19:48 GMT+09:00 Antonio Sanso <asanso@adobe.com>om>:

>  hi John
>
>  On Jun 25, 2015, at 1:42 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> Thanks for the info,
>
> As I read it, this is an attack on Java Script callbacks.
>
> The information tying it to OAuth is not clear.
>
> Is the issue relating to JS people using the implicit flow and the JS
> loaded from the client somehow being vulnerable?
>
> Or is this happening in the JS after authorization in calls to other
> resources from the same origin, and it is just coincidence that people are
> using OAuth.
>
>
>  is more the second one :) Extrapolating from the white paper [0]
>
>  "The most common technique tasked with fullling
> the above described need is OAuth. In order to gain access to third-party
> resources
> using OAuth, the service shall utilize a third-party endpoint (OAuth
> dialog) that will
> ask for the resource owner's approval. The problem with this process is
> that redirecting
> the service to an OAuth dialog means losing the content of the currently
> open service
> document. For overcoming this problem, developers open a pop-up window to
> display
> the dialog in a singular browsing context. Once the user permits or denies
> access to
> the service, the OAuth dialog pop-up will be redirected to render a
> callback endpoint
> hosted on the service domain. This document should eventually notify the
> service that
> the process has been completed.
> For the new pop-up window to notify the service window upon approval,
> denial or for
> it to transfer access tokens or similar data, developers may implement
> callback endpoints
> that use a script referencing the "opener" window for executing a callback
> method of the
> service. When developers also opted for providing the service with the
> decision on how
> to "call it back" through a callback parameter, the entire domain becomes
> vulnerable to
> SOME."
>
>  regards
>
>  antonio
>
>  [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf
>
>
> Understanding if there is any Oauth specific advice to give would be
> helpful.   I see there are ways to prevent the SOME exploit.
>
> Regards
> John B.
>
>
> On Jun 24, 2015, at 4:18 PM, Antonio Sanso <asanso@adobe.com> wrote:
>
> hi *, just sharing.
>
> Not directly related to OAuth per se but it exploits several OAuth client
> endpoints due to some common developers pattern
> http://www.benhayak.com/2015/06/same-origin-method-execution-some.html
> (concrete example in
> http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html
> )
>
> regards
>
> antonio
> _______________________________________________
> 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
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en