[OASIS Issue Tracker] (OSLCCORE-40) Potential click jacking issue for delegated dialogs

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/OSLCCORE-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60981#comment-60981 ] 

James Amsden commented on OSLCCORE-40:
--------------------------------------

From Michael Saylor: 
The issue is that allowing iframe at all opens up an attack surface that if the attacker can exploit allows an overlay of the attack scenario over the window that is framed. The user thinks they are clicking on  one thing, but the attacker makes it click on the framed page instead, doing something nefarious. 
   
The pages in Rational CLM are subject to clickjacking which is what the actual larger issue is. But it applies for OSLC frames as well, I believe, although I am not the expert. A good system would be one that has a whitelist of allowed origins where the iframe can be displayed. This would mean for OSLC standards to have recommendations/specifications on configuring such a whitelist, perhaps?

Our solution is one that sets SAMEORIGIN framing which allows products that are all deployed on the same server to work cooperatively. Alternately, the customer can disable the capability where the products are not on the same server and except the security risk. We have not implemented a whitelisting capability at this time.

I would believe that any product which displays OSLC frames is potentially at risk if the implementation does not set an X-Frame-Options header to at least SAMEORIGIN.

> Potential  click jacking issue for delegated dialogs
> ----------------------------------------------------
>
>                 Key: OSLCCORE-40
>                 URL: https://issues.oasis-open.org/browse/OSLCCORE-40
>             Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC
>          Issue Type: Bug
>            Reporter: James Amsden
>            Assignee: James Amsden
>            Priority: Minor
>
> What
> We have found that MOST of Rational CLM is vulnerable to click jacking attacks, specifically the debug pages are vulnerable so we will use these as an example POC. By inducing victim users to perform actions such as mouse clicks and keystrokes, the attacker can cause them to unwittingly carry out actions within the application that is being targeted. This technique allows the attacker to circumvent defenses against cross-site request forgery, and may result in unauthorized actions.  
> Attack Use Case:
> - An attacker can create an attack page called jts_delete.html
> - Deploy the page to a server
> - Send a link to the Admin
> - When the Admin clicks the link they will be presented with a benign page. Maybe Something Like
>           "Authenticated with BSO"
>                  Click Continue
>                 
> From the screen shot the Attacker has over layed this message on top of the debug console. As a result, the Attacker could align the click with any of the options shown in the screen shot.
> StopAll, RemoveAll, etc... .on other pages there are other 1 click options.
> the point, the screen shot demonstrates that the DEBUG pages (and most pages in CLM) are click jacking vulnerable.
> Remediation
>              
> The Team(s) should review the application functions that are accessible from within the response, and determine whether they can be used by application users to perform any sensitive actions within the application. If so, then a framing attack targeting this response may result in unauthorized actions.
> To effectively prevent framing attacks, the application should return a response header with the name X-Frame-Options and the value DENY to prevent framing altogether, or the value SAMEORIGIN to allow framing only by pages on the same origin as the response itself.  
> The Core TC may want to provide guidance on how to protect from this sort of attack, and implement the prevention mechanism mentioned above. 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)