IMHO forcing users to adopt a new potential breaking feature is a
mistake. We should wait for a wider interest in CSP to enable it by
default. Don't get me wrong, I'm not underestimating the importance of
this feature which is a fantastic tool to ensure security. Nonetheless,
I believe that forcing users to comply with it will only have the effect
of upsetting them.
On 1/21/20 1:27 PM, Emond Papegaaij wrote:
On Tue, Jan 21, 2020 at 12:36 PM Martin Grigorov <[email protected]> wrote:
On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij <[email protected]>
wrote:
I've discussed this with our unit manager, and got permission to
donate our CSP code to Wicket. I think a strong, out of the box CSP is
a killer feature to have for Wicket 9. Not many frameworks can match
this. For this, I would like to continue working on the following
parts:
* Remove all inline styling and JS from Wicket. I will need some help
with this, especially the Form related code.
* Make sure all examples work find with a strong CSP enabled
* Add the CSP code to Wicket and provide several presets (strong,
unsafeJsAndStyling, reportOnly, disabled)
* Enable CSP with the strong preset by default
I think this will break all applications which migrate from earlier version.
I like that Wicket will be more secure by default but
1) most people do not really care about CSP (yet)
2) last time when I tested CSP it was behaving differently on different
browsers. I hope it is better now since only Firefox is not based on
Chromium. According to https://caniuse.com/#search=csp IE11 might be
problematic.
Whatever we choose as default we should document how to switch it on and
off.
The user guide needs to be updated!
Yes, enabling a strict CSP will probably break all existing
applications on upgrade. But the upgrade will do that anyway (I had to
fix quite a few compilation errors to get my app starting again). We
do have to document this in the migration guide. Switching to an
unsafe CSP or disabling it entirely is just one line of code. That's a
lot less work than fixing the compilation errors. I hope enabling CSP
by default will make more people aware of this browser feature. At
Topicus we intent to fix our applications to work with the strict CSP,
probably not directly after migrating to 9, but Wicket 9 is a good
push in this direction.
It is true that support is lacking for some browsers. A browser that
does not support CSP at all (like IE11) is not hindered by it either.
It becomes more problematic when a browser does not support the
directives used (like strict-dynamic). This might cause issues and we
need to test that and change the CSP to make sure it works in those
browsers as well. IMHO as a framework it is our job to set an example
and show how we think this is done best. When a user thinks the gained
security is not worth the pain, he/she can disable it and hope for the
best.
Best regards,
Emond
I've already started the work on the 'csp' branch. On this branch,
I've also migrated all but the servlet API to the jakarta namespace.
Best regards,
Emond
On Sun, Jan 12, 2020 at 8:18 PM Emond Papegaaij
<[email protected]> wrote:
Searching through our Jira, I've found WICKET-6687, filed by Andrew.
He already pinpointed several places that break with a strict CSP
enabled. I'm going to convert that bug into a task (we do not have
epic) and create new bugs for all issues in that ticket. That should
make it easier to track progress.
Best regards,
Emond
On Sat, Jan 11, 2020 at 10:31 PM Emond Papegaaij
<[email protected]> wrote:
Hi all,
For the past few days I've been experimenting with the new CSP
features in Wicket 9. I really want to thank Andrew, Sven and Martin
for the great work you guys did in making this possible. I'm getting
very close to running my application with a very tight and secure CSP.
Unfortunately, some parts of Wicket still use inline styling and
scripting. So far I've found the following two issues:
* hidden components with setOutputMarkupPlaceholderTag(true) have
display:none
* Forms render inline styling and javascript in some cases to improve
submit handling
I think we should try to fix these before Wicket 9 is released. I will
continue to debug our application to see if there are more places.
At Topicus we wrote a IRequestCycleListener that applies the CSP
automatically to every request via HTTP headers. The API makes it easy
to configure the CSP. I've added support for the nonce as well. It
uses a new nonce for every request, which should be more secure than a
nonce bound to a session. I'll discuss with my employee next week if
we can donate this code to Wicket.
Best regards,
Emond
