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 <sakim...@gmail.com> wrote: > > s/Year/Yeah/ > > 2015-06-30 0:22 GMT+09:00 Nat Sakimura <sakim...@gmail.com > <mailto:sakim...@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 <asa...@adobe.com > <mailto:asa...@adobe.com>>: > hi John > > On Jun 25, 2015, at 1:42 AM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@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 > <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 <asa...@adobe.com >>> <mailto:asa...@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 >>> <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 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ <http://nat.sakimura.org/> > @_nat_en > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ <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
