[
https://issues.apache.org/jira/browse/MYFACES-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634224#comment-17634224
]
Werner Punz edited comment on MYFACES-4481 at 11/15/22 9:38 AM:
----------------------------------------------------------------
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
<h:commandLink id="doSubmit" value="booga" action="#{myBean2.execute}">
</h:commandLink>
{code}
would become
{code:html}
<h:commandLink id="doSubmit" value="booga" action="#{myBean2.execute}">
</h:commandLink>
<script nonce="test123">
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
</script>
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handler thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
Unfortunately you cannot automate this over javascript because you are not
allowed to read in the unsecured onclick attribute on js level in the CSP
fortified inline script part.
So theoretically a you can fix this in an automated manner on renderer level,
but not on javascript level. Otherwise you do it by hand on a case by case base.
was (Author: werpu):
Yes, unfortunately what [~melloware] wrote is absolutely correct.
With higher CSP security levels, you will get those errors, because inline
events are then banned due to XSS concerns.
With standard JSF, because the scripts are not externalized, you will get
errors. The fix is exactly like [~melloware] posted.
Unfortunately as of now, standard jsf does not do it that way and this might
have to be challenged in a future spec (or maybe an implementation fix, I am
probably the wrong person to be asked about this).
So what is the workaround.
* You can use a library which does it
* You can use a combination of direct ajax calls jsf.ajax.request, data
attributes or class markers and querySelectorall and/or h:link. Note, *f:ajax*
is out then, so is direct navigation via h:commandLink which also uses inline
event handlers for triggering
* Or you can lower the nonce based security to unsafe-inline and make sure
that you fortify on other levels
* Or you can move the rendered inline event handlers to CSP fortified inline
scripts and override the original ones
here is the idea:
{code:html}
<h:commandLink id="doSubmit" value="booga" action="#{myBean2.execute}">
</h:commandLink>
{code}
would become
{code:html}
<h:commandLink id="doSubmit" value="booga" action="#{myBean2.execute}">
</h:commandLink>
<script nonce="test123">
let commandLink = document.querySelector("#doSubmit");
commandLink.onclick = (evt) => myfaces.oam.submitForm('form1','doSubmit');;
</script>
{code}
So bascially what happens. The inline script throws the error at the time we
click on the element. So in the first case
the page is rendered just fine. But as soon as the user clicks onclick, the CSP
error is thrown.
In the second case we just pushed whatever was rendered (a submitForm call)
into a CSP fortified inline script
and have overridden the onclick handlerd thus erasing the originally unsafe
rendered one. Now if we press the submit
works just as expected.
> HTML event handlers don't work without 'unsafe-inline'
> ------------------------------------------------------
>
> Key: MYFACES-4481
> URL: https://issues.apache.org/jira/browse/MYFACES-4481
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.3-next-M7
> Environment: Chrome: 106.0.5249.103
> Reporter: Vitaly Sidorov
> Priority: Major
>
> HTML event handlers don't work without 'unsafe-inline' in
> 'Content-Security-Policy' header.
> Steps to reproduce:
> - use jsf-2.3-next with fixed bug MYFACES-4479
> - set header Content-Security-Policy: script-src 'self' 'nonce-test123'
> - set <h:outputScript pt:nonce="test123" library="javax.faces" name="jsf.js"
> target="head"/>
> - add h:commandLink inside h:form
> - set parameters
> org.apache.myfaces.USE_MULTIPLE_JS_FILES_FOR_JSF_UNCOMPRESSED_JS=false and
> javax.faces.PROJECT_STAGE=Developement
> - open page in browser and click to link
> - get error in console:
> {{Refused to execute inline event handler because it violates the following
> Content Security Policy directive: "script-src 'self' 'nonce-test123'".
> Either the 'unsafe-inline' keyword, a hash ('sha256-...'), or a nonce
> ('nonce-...') is required to enable inline execution. Note that hashes do not
> apply to event handlers, style attributes and javascript: navigations unless
> the 'unsafe-hashes' keyword is present.}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
