Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Date: Tue, 22 Nov 2011 21:02:39 +0000 (UTC)
From: "Gabrielle Crawford (Updated) (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Message-ID: 
 <1854705778.3853.1321995759964.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1422571192.759.1321924240603.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (TRINIDAD-2169) add framebusting support to handle
 clickjacking attacks
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/TRINIDAD-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gabrielle Crawford updated TRINIDAD-2169:
-----------------------------------------

    Status: Patch Available  (was: Open)
    
> add framebusting support to handle clickjacking attacks
> -------------------------------------------------------
>
>                 Key: TRINIDAD-2169
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2169
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>            Reporter: Gabrielle Crawford
>         Attachments: trin2169.patch
>
>
> First you need to understand clickjacking, which is a security issue when using frames (meaning a frame or iframe). Here's some sites that explain it
>     http://en.wikipedia.org/wiki/Clickjacking
>     http://www.imperva.com/resources/glossary/clickjacking_ui-redressing.html
>     http://seclab.stanford.edu/websec/framebusting/framebust.pdf
> With framebusting we would have support so that an app can say whether its pages are allowed to run in a frame. This will be controlled with a new context parameter "org.apache.myfaces.trinidad.security.FRAME_BUSTING". Values are:
> 1. always: always bust frames, meaning don't allow a page to be embedded in frames
> 2. never: never bust frames, meaning always allow a page to be embedded in frames
> 3. differentOrigin: only bust frames if the an ancestor window origin (protocol, host, and port) and the frame origin are different.
>                          If the ancestor windows and frame have the same origin then allow the content to run in a frame.
>                          For more infomation on origins see http://en.wikipedia.org/wiki/Same_origin_policy
> For example in web.xml you'd add something like this:
> <context-param>
>   <param-name>org.apache.myfaces.trinidad.security.FRAME_BUSTING</param-name>
>   <param-value>differentOrigin</param-value>
> </context-param>
> The default should be at least differentOrigin, because the default needs to be secure, however differentOrigin is not backwards compatible.
> We will not framebust when a portal, portals have a concept of producers and consumers. The main page is the consumer, and the portlets inside that page are the producers. Producer content can only be accessed by trusted consumers.The consumer page can set the context param as needed, but the producers will not do framebusting. In other words, producers will rely on the consumer to address this security issue and, as such, when ExternalContextUtils.isPortlet is true then our producer will behave as if the context parameter is set to 'never'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira