https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |black23@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@bywatersolutions.com, | |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 Benjamin Daeuber <bdaeuber@cityoffargo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdaeuber@cityoffargo.com --- Comment #2 from Benjamin Daeuber <bdaeuber@cityoffargo.com> --- We're currently experimenting with this in response headers in Apache, though part of the struggle is getting a hold on the variety of resources we're currently loading. Paypal, cover images, analytics scripts, enhanced content, jquery libraries, etc, etc. Is the thought to do this with meta tags or using response headers? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #3 from David Cook <dcook@prosentient.com.au> --- Disabling inline Javascript is cool. I wonder how much work it would take to move our inline Javascript into separate scripts. Probably quite a bit as I think there are quite a few places where we generate inline Javascript using templates and Perl scripts... although surely a lot of that Javascript could be re-engineered to work as a separate script without being created dynamically... I suppose there could be a few options about how to turn OpacUserJS into a Javascript file to be loaded by the browser. Could create the file at save time (it's been tempting to add hooks for system preferences for a long time for validation purposes but here would be another use case), or we could point the "src" attribute at a Perl endpoint that spits out Javascript I suppose. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=30263 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #5 from Jake Deery <jake.deery@ptfs-europe.com> --- Hi, We are seeing more and more customers flag this in their security audits. Is there anything that can be done to expedite this bug (I was planning on taking a look at this myself in the near future, but if anyone has already taken an in-depth look, I would be more than happy to collaborate / offer a helping hand). In the land of Moodle, of which I was previously familiar, we used a combination of a SASS compiler to generate and deposit CSS user customisations from database to a file, and JShint to do the same for user JS user customisations. This has the added benefit of not having to call a Perl script more than once. Could this be applicable to Koha's usecase? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #7 from Jake Deery <jake.deery@ptfs-europe.com> --- Hi Michal, I agree; long-term, having a syspref or sysprefs to manage these things would be preferable. In the meantime, I think our starting goal should be implementing something along the lines of: # Disable unsafe inline/eval, only allow loading of resources (images, fonts, scripts, etc.) over https # Note that this does not provide any XSS protection Content-Security-Policy: default-src https: ... as a basic (mandatory) rule. It does not provide any real security gains, but it begins to encourage good practice regarding not placing JavaScript inline in future (as it simply won't work). Once we've covered this as a base, I think that would be the time to move on to adding stricter and more customisable CSP headers. Discussion time; what are everyone's thoughts on this? I could perhaps write a patch as a proof-of-concept? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #9 from Jake Deery <jake.deery@ptfs-europe.com> --- Katrin - I didn't realise you could set 'unsafe-inline'. That would be a great first step, and something we could probably implement quite quickly with minimal disruption :-) The OpacUserJs problem is one that will need more thought and discussion. There are many ways to solve it, each with different benefits and drawbacks in my eyes * You could keep everything in the database, and have a Perl script fetch it on each pageload. E.g. <script src="/cgi-bin/koha/opac-userjs.pl"></script>. This has the benefit of keeping everything in the database, but the drawback of being slow (you're making a dynamic call on each pageload). * Or, you can keep everything in the database, and rebuild a file when you save the syspref. For example, using a filehandler to write to somewhere in /var/lib/koha (or another location, /tmp maybe?). This has the benefit of being faster and cachable using Apache headers, but the drawback of maybe being inconsistent for sites that are configured poorly. * The other option is to maybe do a bit of both? Keep everything in the database, but have the option in the Koha sysprefs page of having a save button and a rebuild button separate from each other. So you can manually rebuild the JS file in the filesystem if it becomes unusable or missing! Of course, these are ideas - and I have COVID at the moment, so I may be writing 100 words where I would usually find what I need to say in ten. Again - open discussion; please say if you think these ideas are all silly, or not useful for Koha's usecase. :-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #11 from Jake Deery <jake.deery@ptfs-europe.com> --- Thank you, so far it's been very mild, so thankfully I'm feeling I will pass through it quickly and be able to return to normality soon! That's a valid point! Plus, provided the file is being stored somewhere that is unlikely to be touched, it shouldn't be an issue (assuming the static file route is chosen). I believe this is the case, too, using Memcached? While this is definitely beneficial from a performance standpoint, if delivering via a Perl script is chosen, it still wouldn't be quite as fast as using static files with 'Expire' headers set in the Apache2 config. In theory - the weight of Perl could be reduced a bit by moving this stuff out to static files! But it does come with the downside of having to manage the static file, and handle the behaviour quirks of that file being managed. My experience in Koha is still quite new - so I don't know how good it is at things like file management and database access! Do you think Koha/Perl is performant enough to make the benefit of static files worthwhile? And do you think on busier systems, the reduction of frequent dynamic requests to a Perl script would be beneficial enough to warrant a static file in place of a Perl script request? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #13 from Jake Deery <jake.deery@ptfs-europe.com> --- Thanks for all your input, Katrin! I'll probably be back with some more questions, when I think of some. I need to get into the habit of using IRC to chat with everyone! :-) I can see this as being possibly a very good way to add new functionality, though! Take CSS, where we could introduce CSS::Sass to the mix and make OpacUserCss work with SASS for some super cool results (OpacUserScss)!! Or with JavaScript::JSLint for JavaScript validation prior to save ;-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 Patrick Robitaille <patrick.robitaille@collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |patrick.robitaille@collecto | |.ca -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- For our inline scripts (like OpacUserJS and IntranetUserJS), we could use a nonce. We'd need to generate the nonce and pass it to the $template in C4::Auth::get_template_and_user(). Then we could easily place it into whatever inline script we need. It wouldn't prevent XSS where we've made an error in our inline script, but it would prevent a lot of stored and reflected XSS in other contexts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- Created attachment 154580 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=154580&action=edit Bug 20397: Add default Content-Security-Policy This patch adds a default Content-Security-Policy to Koha, and includes a mechanism for generating a nonce so that our current inline <script> elements will still work. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- Created attachment 154582 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=154582&action=edit Bug 20397: Add CSP nonce to all OPAC <script> elements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20397 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- However, overall, I'm pretty pleased with this change. I've done some testing and it works very well, and at a glance Koha seems to keep working. (Adding that "nonce" really makes all the difference in allowing us to implement CSP without major changes.) That said, I would appreciate people spinning through some of their favourite functionality to make sure that everything is working. This would be a good one to get in at this point in the release cycle, since there is still lots of time to find problems. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.