https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37573 --- Comment #11 from Michał <schodkowy.omegi-0r@icloud.com> --- I don’t think that’s right. If Koha was to limit where scripts are able to execute, it should do it universally and non-discriminatorily across all prefs and other places alike where HTML can be inserted. With the way things are currently, broken greedy token parsing is by all means a bug and unexpected behavior. The coincidental alignment of its practical end effect with one of long-term goals of Koha development shouldn’t stop its fixing… It shouldn’t willingly be kept broken for this reason. JavaScript is not the only thing someone could have there. Imagine someone could want to put a HTML attribute like data-json='{"something":1}' for example. It’s not JavaScript, and props like that are used sometimes, it’s another “safe” use-case that’s being broken.
but this patch would allow a lot of potential tokens to split through still
I mean having them adhere to some common and very specific format unlikely to conflict with random things is infinitely better than parsing that matches anything in between {} and thus breaks stuff.
I'm going to open a new bug report which will specifically prevent the injection of Javascript via this system preference.
I think one should be opened for all HTML system prefs and things like this alike, I don’t see a reason to single out this one specifically (I think there are more, right?). Also not sure if this blockage can really be done properly without using nonces. Naive breaking such as removing {} does not currently prevent JS code without code blocks from running at all. Matching <script> tags also has a lot of caveats. I’m not sure if any temporary solution other than the said eventual planned script execution source limiting via CSP would make much sense. -- You are receiving this mail because: You are watching all bug changes.