9

I would like to use Content Security Policy for my JSF 2.1 based Web projects as I think it could improve protection against XSS attacks significantly.

Due to CSP's default behaviour to block all inline JavaScript it basically breaks JSF's 

<f:ajax execute="input" render="output" />

functionality. This is because JSF generates lots of inline JavaScript code when using the above stated construct.

Does anybody know if there is a way to use CSP in JSF based projects which make use of f:ajax without the need to allow inline JS by using the following CSP directive:

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

I know that manually placing all of the JavaScript in a separate file would be possible, but doing so I would be forced to do all the Ajax stuff manually.

Mark Pattison
  • 2,964
  • 1
  • 22
  • 42
t3chris
  • 1,390
  • 1
  • 15
  • 25
  • You didn't mark the answer as accepted, so I'm assuming you didn't do it that way, if so how did you do it ? – Ced Mar 24 '16 at 20:08

1 Answers1

4

You could avoid using the unsafe-inline source-expression in order to whitelist inline <script>s, by utilizing nonce and/or hash instead [1]. Doing so would require:

  • Inclusion of a nonce attribute in inline <script> elements, e.g.

    <f:ajax ... pt:nonce="$placeHolder" />

    (assuming that the pt prefix has been bound to the http://xmlns.jcp.org/jsf/passthrough namespace). The attribute's value could just be a placeholder within the view file, enabling you to replace it collectively in all trusted inline <script>s later on.

  • Replacement (via a Filter, for instance) of the placeholder with a random value in each response and insertion of that value into the CSP HTTP Header and/or equivalent <meta> element, producing for example

    <script ... nonce="126cfb..."> and

    Content-Security-Policy: default-src 'self'; ... script-src 'self' 'nonce-126cfb...'.

    Theoretically, produced nonce-values should also be stored on the server, to avoid their reassignment in the near future, since they're supposed to be unique.

  • Additionally or alternatively, insertion of each trusted inline <script> contents' digest into the CSP HTTP Header and/or equivalent <meta> element, alongside its respective hash-algo, such as

    Content-Security-Policy: script-src 'sha256-126cfb...='.

    hash-values should too be regenerated while preparing each response, I guess, since <script>s are generally expected to change over time and with JSF you might not immediately notice when they do.

Uux
  • 1,218
  • 1
  • 10
  • 21