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 89FE21A1B20 for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 08:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HKvjIiIXu0Nj for <oauth@ietfa.amsl.com>; Mon, 29 Jun 2015 08:22:55 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 3B4651A1B4A for <oauth@ietf.org>; Mon, 29 Jun 2015 08:22:55 -0700 (PDT)
Received: by obpn3 with SMTP id n3so106928170obp.0 for <oauth@ietf.org>; Mon, 29 Jun 2015 08:22:54 -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=lRqb8XAaLCu4amPGCLpA80MkVVdrSJYPbpQKs2l244Q=; b=qUT5kk7rFCIxCJWTJ9CouDXi6/I3hyr9fUAH5IYQOFCGDhtidjS0qRJ/Lq3Jlli4f8 CmKGAzsg7LOL0CWTm2+Q4uCXYkHrF8MzmYdrOB28FwUGjKpZc+PY559X+Chxxg6qfOxo 1OX3PZFoVBvc+tHn1fc0P2tVC6poyl9r6hLNP9NH6bJPPSYiKBZATky0nCTHgqp3Ji74 q3xGF2oC0gKXccFdyqTL4di82hiqQBbFo9Nw00N0rgwZVSKmFBO7fsK9F97yCyTTo124 8cA4dVr0xA0LeYY0A7y3D4rfQR5Sqs6YmGrGbGihFzzGfszP6D3RBI3DB8dGp8XXZKZe +akA==
MIME-Version: 1.0
X-Received: by 10.60.79.97 with SMTP id i1mr15087308oex.44.1435591374718; Mon, 29 Jun 2015 08:22:54 -0700 (PDT)
Received: by 10.60.164.97 with HTTP; Mon, 29 Jun 2015 08:22:54 -0700 (PDT)
In-Reply-To: <CABzCy2AA+MbxS-_GX3m-cYL9GVdOYjLhkEYGVb4q_8wbz7wUjQ@mail.gmail.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>
Date: Tue, 30 Jun 2015 00:22:54 +0900
Message-ID: <CABzCy2CizHGqQFyMvo2BKHZHC0JgVqweK=YS7Ycsb01o2cfE1g@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Antonio Sanso <asanso@adobe.com>
Content-Type: multipart/alternative; boundary=089e011848e8eecd4a0519a9a9a7
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/U3C-8S0nnC7YcjG776B6LV38lCY>
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:57 -0000

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