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]>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]> 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 -~----------~----~----~----~------~----~------~--~---
