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

s/Year/Yeah/

2015-06-30 0:22 GMT+09:00 Nat Sakimura <sakimura@gmail.com>:

> 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>:
>
>>  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