I agree with the marketable value of CSP but I don't think it will lose appeal if we make it disabled by default. As I said, I agree to eventually enable it by default, but I don't think the time is ripe yet.
On Tue, Jan 21, 2020 at 2:27 PM Martijn Dashorst <martijn.dasho...@gmail.com> wrote: > Not sure if enabling it by default is a bad thing when you can, as per > migration guide, disable it with one statement in your > WebApplication#init(). > > Also, when looking at marketable features, having CSP, and enabled by > default, is something that publications will take notice of. Just like > being Jakarta EE prepared: > > "Deliver Secure Future Proof Web Applications with Apache Wicket 9 > > Apache Wicket 9 delivers Content Security Policy (CSP) protection > out-of-the-box, protecting web applications against a variety of web > based attack vectors. CSP is a cross-browser technology that prevents > several attacks on web applications by limiting the .... > > With the adoption of the Jakarta EE standards, Apache Wicket 9 is one > of the first Java frameworks prepared for the new future of enterprise > Java. <insert blurb about licensing etc> > " > > Martijn > > 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 > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > -- Andrea Del Bene. Apache Wicket committer.
