You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Maxim Solodovnik <so...@gmail.com> on 2018/08/01 07:18:40 UTC
Re: Content Security Policy support
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 :)
On Mon, Jul 30, 2018 at 3:50 PM Major Péter <ma...@gmail.com> wrote:
>
> 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
>
> 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta:
> > Have you already read this part of the guide?
> > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks
> > On Mon, Jul 30, 2018 at 3:18 PM Major Péter <ma...@gmail.com> wrote:
> >>
> >> 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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
WBR
Maxim aka solomax
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Content Security Policy support
Posted by Maxim Solodovnik <so...@gmail.com>.
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 :(
On Wed, Aug 1, 2018 at 2:32 PM Major Péter <ma...@gmail.com> wrote:
>
> 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
>
> 01/08/2018 08:18 keltezéssel, Maxim Solodovnik írta:
> > 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 :)
> > On Mon, Jul 30, 2018 at 3:50 PM Major Péter <ma...@gmail.com> wrote:
> >>
> >> 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
> >>
> >> 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta:
> >>> Have you already read this part of the guide?
> >>> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks
> >>> On Mon, Jul 30, 2018 at 3:18 PM Major Péter <ma...@gmail.com> wrote:
> >>>>
> >>>> 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-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
WBR
Maxim aka solomax
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Content Security Policy support
Posted by Major Péter <ma...@gmail.com>.
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
01/08/2018 08:18 keltezéssel, Maxim Solodovnik írta:
> 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 :)
> On Mon, Jul 30, 2018 at 3:50 PM Major Péter <ma...@gmail.com> wrote:
>>
>> 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
>>
>> 30/07/2018 09:21 keltezéssel, Maxim Solodovnik írta:
>>> Have you already read this part of the guide?
>>> https://ci.apache.org/projects/wicket/guide/8.x/single.html#_external_security_checks
>>> On Mon, Jul 30, 2018 at 3:18 PM Major Péter <ma...@gmail.com> wrote:
>>>>
>>>> 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-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org