Yahoo¹s security team has concerns regarding the immediate mode and shared computers.
Consider the case where a browser based JS app is running in a browser tab with credentials belonging to a particular user. While the app is still running, the original user lets a friend borrow the browser. The friend opens another tab, logs the original user out of the Service Provider, and then logs in as different user using the friend¹s account. At this point the app is still running as the original user a different tab. If the app¹s credentials expire, it could attempt an immediate request to refresh them which could then return the credentials belonging to the 2nd user. Since this is a JS app the data that belongs to the first user is already loaded, so the app could start co-mingling the data between the two users. At Yahoo, we call this scenario ³crossing the streams² - and that¹s always a really bad thing. This scenario could be really disastrous if the SP has a login CSRF vulnerability meaning that an attacker can CSRF the victim¹s browser into logging in with the attacker¹s account. This vulnerability would result in the victim¹s data mixing with the Attacker. One possible way to prevent this issue is for the client to pass the user¹s identifier (or access token/refresh token/etc) in the immediate request. Allen On 5/24/10 1:05 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: > I am more interested in how you plan to address the (long term) security and > privacy issue: who is responsible to prevent one user in getting an access > token for another in a shared computer environment. As long as the user goes > to facebook.com, you show they who is logged in clearly, so if it is not them, > they can log out. > > But using immediate without a username, it sounds to me like you expect the > client to do the right thing. Is this how you plan to address this? Ask the > client to find out whose access token it got, display it to the user, and > allow them to correct this? Especially given that at this point the client > account is already ³paired² with the access token. > > EHL > > > On 5/24/10 12:44 PM, "Luke Shepard" <lshep...@facebook.com> wrote: > >> Suppose the client does not have a username - say, because the cookie >> expired. What is the appropriate behavior? >> >> Would you require the client to spawn a popup or redirect to a full page auth >> every time a user revisits their site? This doesn't make sense. >> >> Under what circumstances do you think the client gives an access token that >> belongs to another user? If the user is logged into the service provider, >> then they can get that access token anyway by just visiting the service >> provider ... >> >> On May 24, 2010, at 11:18 AM, Dick Hardt wrote: >> >>> > >>> > On 2010-05-24, at 8:55 AM, Eran Hammer-Lahav wrote: >>> > >>>> >> >>>> >> >>>>> >>> -----Original Message----- >>>>> >>> From: Dick Hardt [mailto:dick.ha...@gmail.com] >>>>> >>> Sent: Monday, May 24, 2010 7:35 AM >>>>> >>> To: Eran Hammer-Lahav >>>>> >>> Cc: OAuth WG (oauth@ietf.org) >>>>> >>> Subject: Re: [OAUTH-WG] 'immediate' without identity >>>>> >>> >>>>> >>> You were looking for use cases for immediate without identity. >>>>> >>> >>>>> >>> I agree that *if* the client does know the user, then it should tell >>>>> the server. >>>>> >>> Are you saying that if the client does not know the user it should not use >>>>> >>> immediate? >>>> >> >>>> >> I think the server should reject an immediate request without a >>>> username. Otherwise the server will be giving the client an access token >>>> that belongs to another user. >>> > >>> > Now I understand. I agree. >>> > >>> > -- Dick >>> > >>> > _______________________________________________ >>> > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
