ICEfaces
  1. ICEfaces
  2. ICE-11533

Investigate feasibility of supporting CSP level 2

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces EE

      Description

      We have a customer who is trying to implement a Content-Security-Policy (CSP) Level 2 for their ICEfaces applications.

      We should research the requirements for this and document what resources ICEfaces itself requires to be included as a first step, with potentially including a Level 2 CSP filter in future ICEfaces releases if that is appropriate and feasible.

        Activity

        Hide
        Mircea Toma added a comment - - edited

        The research for CSP level 2 support in ICEfaces shows that the core and its components are fundamentally not suited for a strict CSP implementation. There are various reasons which are described below:

        • ICEfaces core and components use inline JS event handlers (such as onclick, onkeypress ...), for them to work unsafe-hashes policy needs to be used (see https://content-security-policy.com/unsafe-hashes/ ) together with the corresponding calculated hashes. This approach already makes the CSP security less strict.
        • Hashes for inline code and inline event handlers can be calculated easily by ICEfaces core and sent during page load. The problem is that ICEfaces will subsequently partially update the page and introduce new inline code and inline event handlers. Sending these new hashes over AJAX responses does not make the browser take them into account as additional CSP policy.
        • CSP level 3 introduces strict-dynamic policy that can help with subsequently loaded inline code (by previously secured code) but the policy works only with inline code that was not introduced by the markup parser. Unfortunately Mojarra, Myfaces, ICEfaces core and ICEfaces components use HtmlElement.innerHTML property to parse markup and evaluate inline code. Also CSP level 3 is just in draft phase and just partially implemented by browsers.

        Although CSP level 2 support is not possible ICEfaces uses alternative mechanisms to combat XSS (Cross-site Scripting):

        Show
        Mircea Toma added a comment - - edited The research for CSP level 2 support in ICEfaces shows that the core and its components are fundamentally not suited for a strict CSP implementation. There are various reasons which are described below: ICEfaces core and components use inline JS event handlers (such as onclick , onkeypress ...), for them to work unsafe-hashes policy needs to be used (see https://content-security-policy.com/unsafe-hashes/ ) together with the corresponding calculated hashes. This approach already makes the CSP security less strict. Hashes for inline code and inline event handlers can be calculated easily by ICEfaces core and sent during page load. The problem is that ICEfaces will subsequently partially update the page and introduce new inline code and inline event handlers. Sending these new hashes over AJAX responses does not make the browser take them into account as additional CSP policy. CSP level 3 introduces strict-dynamic policy that can help with subsequently loaded inline code (by previously secured code) but the policy works only with inline code that was not introduced by the markup parser. Unfortunately Mojarra, Myfaces, ICEfaces core and ICEfaces components use HtmlElement.innerHTML property to parse markup and evaluate inline code. Also CSP level 3 is just in draft phase and just partially implemented by browsers. Although CSP level 2 support is not possible ICEfaces uses alternative mechanisms to combat XSS (Cross-site Scripting): Parameters used by JSF and ICEfaces core are validated to ensure their values don't contain rogue code. ICEfaces output components (server side) escape the rendered text thus avoiding the evaluation any inline markup or code. See the list of fixes made against XSS: http://jira.icesoft.org/browse/ICE-2184?jql=status%20in%20(Resolved%2C%20Closed%2C%20Done)%20AND%20text%20~%20%22cross-site%22

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Easton Bittner
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: