Summary: | Use HTML escape in templates where appropriate | ||
---|---|---|---|
Product: | Koha | Reporter: | Rick Welykochy <rick> |
Component: | Templates | Assignee: | Owen Leonard <oleonard> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | PATCH-Sent (DO NOT USE) | CC: | chris, cnighswonger, dubyk, paul.poulain |
Version: | 3.6 | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Bug Depends on: | 3652 | ||
Bug Blocks: | |||
Attachments: |
Patch for categorie.tmpl
Corrected patch for categorie.pl Proposed fix Incremental fix for Bug 2847, Use HTML escape in templates where appropriate Proposed fix for 3.4.x |
Description
Chris Cormack
2010-05-21 00:57:08 UTC
Created attachment 6294 [details] [review] Proposed fix Fixes for output in a couple of acquisitions templates where user-generated data should be escaped. This instances were found by creating a vendor name like "Baker & Taylor" and finding that the ampersand was not escaped, causing validation errors. This patch also consolidates multiple <script> blocks which do not need to be separate and corrects a couple of unclosed <input> tags. Created attachment 6299 [details] [review] Incremental fix for Bug 2847, Use HTML escape in templates where appropriate Fixes for output in a couple of acquisitions templates where user-generated data should be escaped. This instances were found by creating a vendor name like "Baker & Taylor" and finding that the ampersand was not escaped, causing validation errors. This patch also consolidates multiple <script> blocks which do not need to be separate and corrects a couple of unclosed <input> tags. Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz> QA comment: I'm not fan of mixing things in patches (html/js), but it's small & announced, so passed QA Patch pushed, please test This patch does not apply cleanly to the 3.4.x branch. If it should, please rebase over that branch and attach the corrected path to this bug report. cnighs@erasmus:~/koha.3.2.test (3.4.x)$ ./get_commits.pl -b 3.4.x -l 35234b478a Shall I apply the bugfix(s) for 2847? (Y/n)y Automatic cherry-pick failed. After resolving the conflicts, mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result with: git commit -c bfe06ef399da831e5602784fbe54cea6dfc1ab65 is it just a problem on 3.4 ? it's OK for 3.6 ? In this case, I think we can stay without this fix in 3.4 : it's a security issue, I agree, but: * it's staff related, so, to exploit such a bug, one would first need to have a valid login, so, the risk is low according to me. * 3.4 EOL is probably close (In reply to comment #5) > is it just a problem on 3.4 ? it's OK for 3.6 ? > In this case, I think we can stay without this fix in 3.4 : it's a security > issue, I agree, but: > * it's staff related, so, to exploit such a bug, one would first need to have a > valid login, so, the risk is low according to me. IMHO any security issue should be backported into any currently maintained branch. > * 3.4 EOL is probably close Not as close as we might imagine. As long as commits will apply, I plan on keeping 3.4.x alive until we reach a year from 3.6.x release. Created attachment 6380 [details] [review] Proposed fix for 3.4.x Included in the 3.6 branch prior to 3.6.4. |