We are not forcing uses to comply with a strict CSP when we enable it by default. It's just a setting, which can be turned off with a single line of code that will be put in the migration guide. Enabling this by default will however protect new applications out of the box and raise the awareness of this feature. Our examples can serve as a guide on how to use this.
Emond On Tue, Jan 21, 2020 at 2:00 PM Andrea Del Bene <an.delb...@gmail.com> wrote: > > 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 <mgrigo...@apache.org> > > wrote: > >> On Mon, Jan 13, 2020 at 11:15 PM Emond Papegaaij > >> <emond.papega...@gmail.com> > >> 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 > >>> <emond.papega...@gmail.com> 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 > >>>> <emond.papega...@gmail.com> 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
