Content Security Policy support

[Major Péter]

Hi,

I'm trying to write a new Wicket application, and I wanted to use CSP
for added security. It seems like that there are two main issues:
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles

Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?

Alternatively, I was thinking of a couple of ways to overcome these
issues, like:
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.

Are these approaches any good?

Thanks,
Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@wicket.apache.org
For additional commands, e-mail: users-***@wicket.apache.org

[Maxim Solodovnik]

Have you already read this part of the guide?
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks

Post by Major Péter
Hi,
I'm trying to write a new Wicket application, and I wanted to use CSP
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles
Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?
Alternatively, I was thinking of a couple of ways to overcome these
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.
Are these approaches any good?
Thanks,
Peter
---------------------------------------------------------------------

[Major Péter]

Hi,

thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8
years, so I was still thinking that Confluence was the source of truth).

Reading through the section I don't feel that the suggestion there is
appropriate:
* using default-src https: allows to do pretty much anything as long as
the resource being loaded is over HTTPS (and getting a cert for free is
a pretty easy thing to do).
* IMHO setting default-src to 'none' and then one-by-one whitelisting
all the resource types is a better approach as it is much more limiting
* By enabling https: resources only, the "unsafe-inline" and
"unsafe-eval" requirements for script-src are not covered, and hence
Wicket's AJAX components won't actually work (well the fallback impls will).
* This also doesn't tackle the style-src unsafe-inline requirements.

Do you want me to file a doc bug for this?

Regards,
Peter

Post by Maxim Solodovnik
Have you already read this part of the guide?
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks

Post by Major Péter
Hi,
I'm trying to write a new Wicket application, and I wanted to use CSP
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles
Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?
Alternatively, I was thinking of a couple of ways to overcome these
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.
Are these approaches any good?
Thanks,
Peter
---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@wicket.apache.org
For additional commands, e-mail: users-***@wicket.apache.org

[Maxim Solodovnik]

Hello Peter,

I also believe the general rule should be: deny All then allow one-by-one
but this is general principle, the guide describing some configuration
you can start with :)

Post by Major Péter
Hi,
thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8
years, so I was still thinking that Confluence was the source of truth).
Reading through the section I don't feel that the suggestion there is
* using default-src https: allows to do pretty much anything as long as
the resource being loaded is over HTTPS (and getting a cert for free is
a pretty easy thing to do).
* IMHO setting default-src to 'none' and then one-by-one whitelisting
all the resource types is a better approach as it is much more limiting
* By enabling https: resources only, the "unsafe-inline" and
"unsafe-eval" requirements for script-src are not covered, and hence
Wicket's AJAX components won't actually work (well the fallback impls will).
* This also doesn't tackle the style-src unsafe-inline requirements.
Do you want me to file a doc bug for this?
Regards,
Peter

Post by Maxim Solodovnik
Have you already read this part of the guide?
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks

Post by Major Péter
Hi,
I'm trying to write a new Wicket application, and I wanted to use CSP
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles
Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?
Alternatively, I was thinking of a couple of ways to overcome these
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.
Are these approaches any good?
Thanks,
Peter
---------------------------------------------------------------------

---------------------------------------------------------------------

[Major Péter]

Hi,

In that case I would suggest default-src 'self' as a better starting
point. The problem remains though, if one uses Ajax and/or has
placeholder tags for invisible components, one must have at least:
Content-Security-Policy: script-src 'self' 'unsafe-inline'
'unsafe-eval'; style-src 'self' 'unsafe-inline'

I'd wonder whether the style="display:none" cases would be simpler to
deal with by whitelisting its hash rather than trying to come up with a
Wicket specific CSS resource only to define a class for that purpose...

cheers,
Peter

Post by Maxim Solodovnik
Hello Peter,
I also believe the general rule should be: deny All then allow one-by-one
but this is general principle, the guide describing some configuration
you can start with :)

Post by Major Péter
Hi,
thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8
years, so I was still thinking that Confluence was the source of truth).
Reading through the section I don't feel that the suggestion there is
* using default-src https: allows to do pretty much anything as long as
the resource being loaded is over HTTPS (and getting a cert for free is
a pretty easy thing to do).
* IMHO setting default-src to 'none' and then one-by-one whitelisting
all the resource types is a better approach as it is much more limiting
* By enabling https: resources only, the "unsafe-inline" and
"unsafe-eval" requirements for script-src are not covered, and hence
Wicket's AJAX components won't actually work (well the fallback impls will).
* This also doesn't tackle the style-src unsafe-inline requirements.
Do you want me to file a doc bug for this?
Regards,
Peter

Post by Maxim Solodovnik
Have you already read this part of the guide?
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks

Post by Major Péter
Hi,
I'm trying to write a new Wicket application, and I wanted to use CSP
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles
Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?
Alternatively, I was thinking of a couple of ways to overcome these
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.
Are these approaches any good?
Thanks,
Peter
---------------------------------------------------------------------

---------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@wicket.apache.org
For additional commands, e-mail: users-***@wicket.apache.org

[Maxim Solodovnik]

PRs are welcome :))) sources for the guide are located here:
https://github.com/apache/wicket/tree/master/wicket-user-guide/src/main/asciidoc

Ajax components requires 'unsafe-inline' 'unsafe-eval', not sure how
this can be fixed :(

Post by Major Péter
Hi,
In that case I would suggest default-src 'self' as a better starting
point. The problem remains though, if one uses Ajax and/or has
Content-Security-Policy: script-src 'self' 'unsafe-inline'
'unsafe-eval'; style-src 'self' 'unsafe-inline'
I'd wonder whether the style="display:none" cases would be simpler to
deal with by whitelisting its hash rather than trying to come up with a
Wicket specific CSS resource only to define a class for that purpose...
cheers,
Peter

Post by Maxim Solodovnik
Hello Peter,
I also believe the general rule should be: deny All then allow one-by-one
but this is general principle, the guide describing some configuration
you can start with :)

Post by Major Péter
Hi,
thanks, I haven't seen that one yet (I'm coming back to Wicket after ~8
years, so I was still thinking that Confluence was the source of truth).
Reading through the section I don't feel that the suggestion there is
* using default-src https: allows to do pretty much anything as long as
the resource being loaded is over HTTPS (and getting a cert for free is
a pretty easy thing to do).
* IMHO setting default-src to 'none' and then one-by-one whitelisting
all the resource types is a better approach as it is much more limiting
* By enabling https: resources only, the "unsafe-inline" and
"unsafe-eval" requirements for script-src are not covered, and hence
Wicket's AJAX components won't actually work (well the fallback impls will).
* This also doesn't tackle the style-src unsafe-inline requirements.
Do you want me to file a doc bug for this?
Regards,
Peter

Post by Maxim Solodovnik
Have you already read this part of the guide?
https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks

Post by Major Péter
Hi,
I'm trying to write a new Wicket application, and I wanted to use CSP
* Wicket's AJAX support is highly dependent on inline and eval'd
JavaScript code
* component visibility is controlled using inline styles
Is WICKET-5406 going to get some traction anytime soon, or are there
known workarounds for the above issues (like a CSP friendly AJAX
implementation)?
Alternatively, I was thinking of a couple of ways to overcome these
* trying to use one-off resource references (if possible?) for
individual requests, so that instead of eval'ing, the code could be just
simply loaded instead?
* have a way to generate and retrieve nonces for inline resources and
make sure that Wicket sets the CSP header on its own.
* update Wicket itself to use text/json script elements to load its
configuration and pass JSON objects only for AJAX responses, so that
they no longer need to be eval'd.
Are these approaches any good?
Thanks,
Peter
---------------------------------------------------------------------

---------------------------------------------------------------------

---------------------------------------------------------------------