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

From: Antonio Sanso <[email-masked]>
Date: Wed, 24 Jun 2015 19:18:29 +0000

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

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Jun 2015 20:42:36 -0300

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.

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 <[email-masked]> wrote:
> 
> hi *, just sharing.
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 25 Jun 2015 10:48:27 +0000

hi John

On Jun 25, 2015, at 1:42 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for the info,

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

Regards
John B.

On Jun 24, 2015, at 4:18 PM, Antonio Sanso <[email-masked]<mailto:[email-masked]>> wrote:

hi *, just sharing.

regards

antonio
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 30 Jun 2015 00:22:28 +0900

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 <[email-masked]>:

>  hi John
>
>  On Jun 25, 2015, at 1:42 AM, John Bradley <[email-masked]> wrote:
>
> Thanks for the info,
>
> 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.
>
>
> 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.
>
>
> 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

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

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 30 Jun 2015 00:22:54 +0900

s/Year/Yeah/

2015-06-30 0:22 GMT+09:00 Nat Sakimura <[email-masked]>:

>>  "The most common technique tasked with ful lling

---

From: Justin Richer <[email-masked]>
Date: Mon, 29 Jun 2015 11:36:22 -0400

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 <[email-masked]> wrote:
> 
> s/Year/Yeah/
> 
> 2015-06-30 0:22 GMT+09:00 Nat Sakimura <[email-masked] <mailto:[email-masked]>>:
> Year, from my skimming of the paper, it requires a page that executes arbitrary callback function given as a parameter. 
> 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 
> 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 <[email-masked] <mailto:[email-masked]>>:
> hi John
> 
> On Jun 25, 2015, at 1:42 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Thanks for the info,
>> 
> [0] http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf <http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf>
> 
>> 
>>> On Jun 24, 2015, at 4:18 PM, Antonio Sanso <[email-masked] <mailto:[email-masked]>> 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 <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 <http://www.benhayak.com/2015/05/stealing-private-photo-albums-from-Google.html>)
>>> 
>>> regards
>>> 
>>> antonio
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Phil Hunt <[email-masked]>
Date: Mon, 29 Jun 2015 09:25:50 -0700

Or maybe another wg should address (http)?

Phil

> On Jun 29, 2015, at 08:36, Justin Richer <[email-masked]> wrote:
>