Yahoo always requires the user to enter their password (even if the user is already signed into Yahoo) before issuing persistent credentials. The intent is to verify that the user is actually sitting in front of the computer before issuing a persistent credential, to protect against the case where the attacker is trying to backdoor a victim's account, when the victim left their computer unattended, or forgot to logout.
A nice side effect of requiring password verifcation is that a potential clickjacker would need to phish the user before clickjacking the OAuth permissions screen... Allen Josh Roesslein wrote: > A simple way to block this attack would be to force the user to login > each time before displaying the approval page (even if there is a SP > session cookie). This way the attacker > can not load the approval page in a frame. They would need the > password to do so. This does impact the user experience a bit, but > does solve the issue 100% unless I over looked something. > > On Mon, May 4, 2009 at 7:43 PM, Stephen Sclafani <[email protected] > <mailto:[email protected]>> wrote: > > > Allen, > > You are correct about the security attribute being able to disable > frame busting scripts in IE. IE8 supports a X-Frame-Options HTTP > response header which can be used by a developer to deny their > approval page from rendering in a frame. However IE8 is not currently > widely used. Even requiring that javascript be enabled is not a > perfect solution. In my conversation with Google's security team they > informed me that they were going to add frame busting javascript > (which they have done) and possibly add the X-Frame-Options header. I > think that this is the best a service provider can hope to do at this > point. There really is no 100% solution. > > Stephen Sclafani > > On May 4, 4:15 pm, Allen Tom <[email protected] > <mailto:[email protected]>> wrote: > > Hi Stephen, > > > > Thanks for pointing this out. It might not be sufficient to > deploy only > > Framebusting JS on the approval screens, as the attacker can > disable JS > > for the iframe in IE by setting the security attribute to > "restricted" > > > > http://msdn.microsoft.com/en-us/library/ms534622(VS.85).aspx > <http://msdn.microsoft.com/en-us/library/ms534622%28VS.85%29.aspx> > > > > SPs may need to deploy Framebusting JS AND require that JS is > enabled > > for users to approve the Access Token, otherwise the attacker could > > embed the approval screen in an iframe with JS disabled. > > > > Allen > > > > Stephen Sclafani wrote: > > > There has been much discussion over the session fixation > vulnerability > > > since it was announced publicly. There is another issue that > is not > > > unique to OAuth but one that I believe poses an equal if not more > > > serious threat to service providers. That issue is clickjacking. > > > > > For those unfamiliar with clickjacking, it is when a visitor > to a web > > > page is tricked into clicking on an element that they believe > to be > > > harmless when in reality they are clicking on an element on a > > > different website that exposes protected data or grants an > attacker > > > access. A malicious consumer developer can use a clickjacking > attack > > > against a vulnerable service provider's approval page to trick > users > > > into granting their application access. > > > > > Current service providers have been notified. Google, Yahoo and > > > Twitter have already deployed protection. I have written a > blog post > > > that goes into greater detail on the threat which can be read > here: > > > > >http://stephensclafani.com/2009/05/04/clickjacking-oauth/ > > > > > Stephen Sclafani > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
