if you create a "new Patron attribute type" and make it editable via the opac interface, the user input is not checked for js injection. Hence js code may be executed in the admin interface
Created attachment 138072 [details] [review] Bug 31219: Prevent JS injection in patron extended attributes We are sanitizing other attributes but "extended patron attributes". Test plan: Make a patron attribute editable at the OPAC Edit an existing patron, or register a new one Use a script tag in the new value ("<script>alert("booh!")</script>" for instance) With this patch the value is remove if containing an HTML tag that is not br b i em big small strong (see C4::Scrubber)
We could certainly do better here. But not sure we could with a 2-lines patch.
I did a quick test and it worked as expected
I'll add this to my list to check out. Should be a good one to review...
Even without this patch, the code won't be executed when moderating the change requests, but only after accepting the changes.
At the moment, if all that was added is code, the empty field will still be pushed, even if it means 'no change'. Maybe this could be improved a little, but this is still an improvement already.
Created attachment 138234 [details] [review] Bug 31219: Prevent JS injection in patron extended attributes We are sanitizing other attributes but "extended patron attributes". Test plan: Make a patron attribute editable at the OPAC Edit an existing patron, or register a new one Use a script tag in the new value ("<script>alert("booh!")</script>" for instance) With this patch the value is remove if containing an HTML tag that is not br b i em big small strong (see C4::Scrubber) Signed-off-by: Mark Hofstetter <koha@trust-box.at> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Backported: Pushed to 21.05.x branch for the upcoming release (21.05.20)
pushed to oldoldstable right ?