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

Phil Hunt <phil.hunt@oracle.com> Mon, 29 June 2015 16:25 UTC

Return-Path: <phil.hunt@oracle.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 1A6BA1AD0D6 for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.754
X-Spam-Level:
X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 2hNnIAF1gTEI for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 09:25:55 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8FF1ACEBB for <oauth@ietf.org>; Mon, 29 Jun 2015 09:25:54 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5TGPrBP005347 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Jun 2015 16:25:53 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t5TGPqON017944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 29 Jun 2015 16:25:52 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5TGPqP5025742; Mon, 29 Jun 2015 16:25:52 GMT
Received: from [10.0.1.13] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Jun 2015 09:25:52 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-EFDD0985-AE75-4927-AC1F-8E3E9D26CA2B
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (12F70)
In-Reply-To: <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu>
Date: Mon, 29 Jun 2015 09:25:50 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <A101EBCC-5497-4311-8DA9-12AB977F6456@oracle.com>
References: <B1C45938-9B95-4059-8235-0745216DFF60@adobe.com> <DACC2E36-E0E1-47C9-BC8F-CDEB1C13939D@ve7jtb.com> <51B1A21C-4893-403E-AE00-33F4B7827346@adobe.com> <CABzCy2AA+MbxS-_GX3m-cYL9GVdOYjLhkEYGVb4q_8wbz7wUjQ@mail.gmail.com> <CABzCy2CizHGqQFyMvo2BKHZHC0JgVqweK=YS7Ycsb01o2cfE1g@mail.gmail.com> <14F3933F-C943-4B7E-8C92-11CB227FB1A7@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/9t2-fnSUOYoD5ZCPZBz8a3sQ4iw>
Cc: "<oauth@ietf.org>" <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 16:25:57 -0000

Or maybe another wg should address (http)?

Phil

> On Jun 29, 2015, at 08:36, Justin Richer <jricher@mit.edu> wrote:
> 
> Right, even though it’s not an OAuth problem, it’s a problem that is more likely to come up and cause damage in situations that OAuth brings about (the pop-up redirect page that Nat mentions). So, just like the advice to use the system browser on mobile platforms, I think it’d be good to have actual advice for developers so that they can avoid doing this.
> 
>  — Justin
> 
>> On Jun 29, 2015, at 11:22 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>> 
>> s/Year/Yeah/
>> 
>> 2015-06-30 0:22 GMT+09:00 Nat Sakimura <sakimura@gmail.com>om>:
>>> 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 ful lling
>>>> 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
>> 
>> 
>> 
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> 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