https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #1)

Done with a script, see commit 582502644801b44595497caf6bbee449f0347238 Bug 21526: uri escape TT variables when used in 'a href' We may need to adjust some occurrences manually.

I'm not sure what you're saying, Jonathan. Do you mean that the filter was added by the script and that we need to remove the filters manually? If so, what would prevent the filters from being re-added by a script in the future? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #3)

Did you read the commit message and the bug description?

No, I didn't look it up in Git. Like Stackoverflow, I think it makes sense to include the relevant content in the forum rather than sending people off somewhere else. Providing a link isn't the same thing as providing a response.

I wrote a script to guess what needed to be escaped correctly, in <a href=/uri?param=[% value %]>, 'value' must be uri escaped, not html escaped.

I think you've misunderstood me. I'm saying "href="[% ITEM_RESULT.uri | url %]" is a problem because ITEM_RESULT.uri may already contain an escaped URL. For instance, "https://idp.com?redirect_url=https%3A%2F%2Fsomewhere_else.com". If you run use a filter like [% ITEM_RESULT.uri | url %], that'll make it double-encoded which breaks the URL. It's a different use case. I'm not describing building a URL in the template. I'm talking about when an entire URL is already provided. Filtering it is problematic as you can't know how the URL data is already going to be handled. (Although a person could write a filter that parses the URL and escapes any unescaped parameters and rebuilds the URL, but that's also more work that I doubt anyone wants to do right now.)

This is true in ~90% of the situations, others (specific cases) need to be handled separately and fixed manually.

This is what I don't understand. I understand how the template can be fixed manually, but can you explain to me how the scripts for auto-adding filters will ignore manually fixed cases? *clicks through to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21526* Are you referring to use of $raw instead? I don't understand what you're trying to say.

If you found one you can provide a patch and I will test it.

This also confuses me. What do you mean by "one" here? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #5)

If I understand the issue correctly:

Catalogers might copy escaped and unescaped URLs into 856$u/952$u/955? and that leaves us with the problem that we might not use the correct filter in the templates.

I'd say that catalogers might copy URLs into 856$u/952$u/955? that have escaped values in the query string (actually there could also be escaped values in the path - this is common with URLs used in IIIF Image Servers like Loris*), and we don't want to double-encode those values. *Example Loris URL: http://loris.example.org/loris/1234%2F5678%2F90123.tif/info.json

What can we do here? Is there a way to determine safely, if an URL has already been escaped? I assume checking for something like % might work?

I don't know if there is a best practice for checking URL encoding. I don't think there is. When it comes to safety, I think we need to think about the origin of the value. It's not a public end user providing this value; it's an authorized staff member. If this were a CMS, we'd be trusting that the people providing the content for the CMS aren't embedding malicious Javascript, right? I mean... if a staff member wanted to inject Javascript, they could use OpacUserJS. That said, OpacUserJS requires admin privileges. And maybe a less cautious cataloguer could import a MARCXML record with a malicious URL in it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- Using some of the evasion strategies in https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) and Perl's URI->new() is handling it. Ah we can see it at https://metacpan.org/source/OALDERS/URI-1.76/lib/URI.pm#L81 I think. Basically it encodes everything that isn't in the following: our $reserved = q(;/?:@&=+$,[]); our $mark = q(-_.!~*'()); #'; emacs our $unreserved = "A-Za-z0-9\Q$mark\E"; our $uric = quotemeta($reserved) . $unreserved . "%"; Whereas http://template-toolkit.org/docs/manual/Filters.html#section_url encodes everything that is outside the permitted URI charactesrs from RFC 2396, except &, @, /, ;, :, =, +, ? and $. The key thing is how the URI module doesn't encode the % sign. (Of course reading http://template-toolkit.org/docs/manual/Filters.html#section_uri it says ("(", ")", "~", "*", "!" and the single quote "'") now need to be escaped according to RFC3986... and the URI module doesn't do that? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #9)

I find it interesting that the double quote character is safe in RFC 3986... as that's a character I use for crafting my malicious strings.

But in Template 2.28 it is still encoding the double quote character even though it says it doesn't need to... *shrug* -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |jonathan.druart@bugs.koha-c | |ommunity.org Status|NEW |In Discussion --- Comment #12 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Here is a patch for discussion, could you confirm it fixes the issues you faced? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas@bywatersolutions.com --- Comment #14 from Lucas Gass <lucas@bywatersolutions.com> --- I ran into this problem today with double encoded URL parameters if OPACURLOpenInNewWindow is turned on. Not sure why this is In Discussion, I tested Jonathan's patch (which needs rebased) and it seems to work. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- I think removing the "url" filter seems like the more reasonable solution to me. In this case, the ITEM_RESULT.uri is coming from a stored record in the staff interface, so we don't really need to filter unauthenticated untrusted user input. That said, an authenticated user with cataloguing privileges could put in malicious Javascript into a 856$u subfield. (Then again, an authenticated user with admin privileges could put malicious Javascript into OpacUserJS, so an authenticated staff interface user is always a bit of a risk.) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- Template Toolkit uses RFC 2396 (from 1998) for the url filter. Looking at RFC 2396 https://tools.ietf.org/html/rfc2396#section-2.4.2: "Data must be escaped if it does not have a representation using an unreserved character" However, it also says the following: "A URI is always in an "escaped" form, since escaping or unescaping a completed URI might change its semantics. Normally, the only time escape encodings can safely be made is when the URI is being created from its component parts; each component may have its own set of characters that are reserved, so only the mechanism responsible for generating or interpreting that component can determine whether or not escaping a character will change its semantics. Likewise, a URI must be separated into its components before the escaped characters within those components can be safely decoded." Note also the following: "Because the percent "%" character always has the reserved purpose of being the escape indicator, it must be escaped as "%25" in order to be used as data within a URI. Implementers should be careful not to escape or unescape the same string more than once, since unescaping an already unescaped string might lead to misinterpreting a percent data character as another escaped character, or vice versa in the case of escaping an already escaped string." Template Toolkit have changed the behaviour of the "uri" and "url" filters over time (http://www.template-toolkit.org/docs/manual/Filters.html#section_url). I think they also haven't interpreted RFC3986 correctly in regards to the double quote character... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- Consider the following code: #!/usr/bin/perl use strict; use warnings; use URI::Escape; use Template; my $one = uri_unescape('https://www.google.com/url?q=https://buttercup.pw"'); my $two = uri_unescape('https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw%22'); my $template = Template->new(); my $output; $template->process( \*DATA, { one => $one, two => $two }, \$output ); warn $output; __DATA__ [% one | url %] [% two | url %] Consider the output: https://www.google.com/url?q=https://buttercup.pw%22 https://www.google.com/url?q=https://buttercup.pw%22 Actually... while that *looks* good... that's not necessarily correct, because the "correct" URL is actually https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw%22 That said... the end-target will uri_unescape the value of the "q" key anyway, so it shouldn't matter. Plus the URI standard says you may choose not to percent encode the query component due to usability concerns... But our test cases might also be overly simplistic. I wonder if I have any real-life complex URLs for digital resources laying around... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #22 from David Cook <dcook@prosentient.com.au> --- But... doing nothing is also risky. I suppose we could validate that it's actually a URL, but that's easy to bypass. But we can't re-encode the URI components either because that could compromise the semantics of the URL. I suppose one could argue that it's better to compromise the semantics of a good URL than to permit an unchallenged bad URL. We could also check URLs for characters outside the "unreserved character" list, and percent-encode if we find any (by percent encoding components rather than using the "url" filter). You could get false positives but that's better than a false negative. That should prevent XSS and allow through properly encoded URLs (e.g. "https://idp.com?redirect_url=https%3A%2F%2Fsomewhere_else.com"). -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #24 from David Cook <dcook@prosentient.com.au> --- Consider the following code: #!/usr/bin/perl use strict; use warnings; use URI; use Template; my $one = URI->new('https://www.google.com/url?q=https://buttercup.pw"></a><injection></injection><a href="'); my $two = URI->new('https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw'); my $template = Template->new(); my $output; $template->process( \*DATA, { one => $one, two => $two }, \$output ); warn $output; __DATA__ [% one %] [% two %] Consider the following output: https://www.google.com/url?q=https://buttercup.pw%22%3E%3C/a%3E%3Cinjection%... https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw In this case it's let the correctly percent encoded URL through, but it's also encoded the malicious URL. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #89352|0 |1 is obsolete| | --- Comment #25 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 126174 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=126174&action=edit Bug 22223: Try to not double encoded URIs in items.uri This is just a POC and is not ready for inclusion (Filter.pm and naming need to be discussed). Test plan: Create 2 items, with uri: https://www.google.com/url?q=https://buttercup.pw https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw Go to the OPAC detail page of the bib record, see that the links are displayed how you entered them. Click on them and confirm that the uri/page is correct -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |severine.queune@bulac.fr --- Comment #27 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- *** Bug 29208 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #28 from Séverine Queune <severine.queune@bulac.fr> --- Hi Jonathan, Sorry for the duplicate, I searched in Bugzilla before I open my bug but it seems I didn't use good keywords... I tried to apply your POC on Biblibre's sandbox, but I get a "503 Service Unavailable". The patch correctly applies on ByWater's sandbox and it works pretty well ! I did my part, so I let you devs discuss about the points you mentioned :) Thanks ! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #126174|0 |1 is obsolete| | --- Comment #29 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Created attachment 132027 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=132027&action=edit Bug 22223: Try to not double encoded URIs in items.uri This is just a POC and is not ready for inclusion (Filter.pm and naming need to be discussed). Test plan: Create 2 items, with uri: https://www.google.com/url?q=https://buttercup.pw https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw Go to the OPAC detail page of the bib record, see that the links are displayed how you entered them. Click on them and confirm that the uri/page is correct Signed-off-by: Séverine Queune <severine.queune@bulac.fr> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #31 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Nope. It's a common mistake in Koha/Template/Plugin/, certainly coming from a copy/paste. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #33 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Can you provide some regression tests for this? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |tomascohen@gmail.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #133578|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #35 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Created attachment 133589 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=133589&action=edit Bug 22223: Try to not double encoded URIs in items.uri This is just a POC and is not ready for inclusion (Filter.pm and naming need to be discussed). Test plan: Create 2 items, with uri: https://www.google.com/url?q=https://buttercup.pw https://www.google.com/url?q=https%3A%2F%2Fbuttercup.pw Go to the OPAC detail page of the bib record, see that the links are displayed how you entered them. Click on them and confirm that the uri/page is correct Signed-off-by: Séverine Queune <severine.queune@bulac.fr> JD amended patch: * Remove use Template::Plugin::Filter; * Fix license statement Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #37 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Jonathan Druart from comment #34)

Created attachment 133578 [details] [review] Bug 22223: Add tests

Great job, thanks -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #39 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Fridolin Somers from comment #38)

...

This is just a POC No push to master then ?

It *was* a POC, if everybody is happy with the patch I guess you can push it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #41 from David Cook <dcook@prosentient.com.au> --- (In reply to Fridolin Somers from comment #40)

That code looks very strange to me. Naming a TT filter 'Filter'.

I would prefer to see syntax : [% var | $NoDoubleEncode %] Like TT plugin Price.

Class is using : Base qw( Template::Plugin::Filter ) But does not implement a 'filter' method.

I think a good alternative would be what I suggest at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223#c7 as well. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #43 from David Cook <dcook@prosentient.com.au> --- *** Bug 23535 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #45 from David Cook <dcook@prosentient.com.au> --- It looks like it's no longer an issue in the staff interface since we're now constructing this HTML using Javascript in koha-tmpl/intranet-tmpl/prog/en/includes/html_helpers/tables/items/catalogue_detail.inc and we're using our homemade escape function. I'd prefer we created the elements using objects rather than strings and using escape_str, but it escapes the XSS and doesn't double-encode a simple URL, so it seems good enough. The OPAC is still a problem. I'm going to try something... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #133589|0 |1 is obsolete| | Attachment #133590|0 |1 is obsolete| | --- Comment #46 from David Cook <dcook@prosentient.com.au> --- Created attachment 170485 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170485&action=edit Bug 22223: Add filter to make item URLs safe in template output This change adds a "safe_url" filter which takes a text input and returns a Perl URL object which stringifies to a safe URL. This change is only needed in the OPAC as the staff interface handles the item URL display using Javascript not Template Toolkit. 0. Apply patch and koha-plack --restart kohadev 1. Create an item for a record using the following URL https://koha-community.org?url=https%3A%2F%2Fkoha-community.org 2. Go to the OPAC for that record and verify that the URL is not double-escaped 3. Create a malicious payload (talk to QA/security team for this if necessary) 4. Note that the malicious payload is escaped 5. prove t/Koha/Plugins/SafeURL.t 6. Celebrate! -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #48 from David Cook <dcook@prosentient.com.au> --- QA note: FAIL koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt FAIL filters missing_filter at line 1366 ( <a target="[% target_attr | html %]" rel="[% rel_attr | html %]" href="[% uri | safe_url %]" property="url">[% uri | html %]</a>) missing_filter at line 1373 ( <a target="[% target_attr | html %]" rel="[% rel_attr | html %]" href="[% ITEM_RESULT.uri | safe_url %]" property="url">) So... either we need to add a $raw filter after "safe_url" or we need to update the QA tools to deal with this new "safe_url" filter? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|oleonard@myacpl.org |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #50 from Lucas Gass <lucas@bywatersolutions.com> --- (In reply to Gretchen Maxeiner from comment #49)

Hello, we are a library experiencing this issue and I was directed to this ticket. I'm out of my depth on this discussion but I see an assumption that this only affects the OPAC, not the staff interface. This is not true for us -- so I wanted to add that we see it both places.

Our scenario is this: Links in the MARC 856 sometimes contain a space (these links are generated out of a SharePoint where spaces are permitted in naming). These records are then used in Course Reserves. If you try to access the URL from the reserve title list within a course the "Record URL" link fails for these. The "Record URL" link is available for course reserves in both the OPAC and Staff interface, and fails both places.

Thank you all for looking into and working on this issue!

Thanks for your input, Gretchen. David's patch will make it pretty easy to apply this safe_url filter to other places in Koha, like course reserves. I'm going to sign-off here because this works good. As for the QA script, I think it's better to update the script. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Lucas Gass <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #170485|0 |1 is obsolete| | --- Comment #51 from Lucas Gass <lucas@bywatersolutions.com> --- Created attachment 170577 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170577&action=edit Bug 22223: Add filter to make item URLs safe in template output This change adds a "safe_url" filter which takes a text input and returns a Perl URL object which stringifies to a safe URL. This change is only needed in the OPAC as the staff interface handles the item URL display using Javascript not Template Toolkit. 0. Apply patch and koha-plack --restart kohadev 1. Create an item for a record using the following URL https://koha-community.org?url=https%3A%2F%2Fkoha-community.org 2. Go to the OPAC for that record and verify that the URL is not double-escaped 3. Create a malicious payload (talk to QA/security team for this if necessary) 4. Note that the malicious payload is escaped 5. prove t/Koha/Plugins/SafeURL.t 6. Celebrate! Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de --- Comment #53 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Just ran the koha-qa on this. Is this a false positive? FAIL koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-detail.tt FAIL filters missing_filter at line 1372 ( <a target="[% target_attr | html %]" rel="[% rel_attr | html %]" href="[% uri | safe_url %]" property="url">[% uri | html %]</a>) missing_filter at line 1379 ( <a target="[% target_attr | html %]" rel="[% rel_attr | html %]" href="[% ITEM_RESULT.uri | safe_url %]" property="url">) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #55 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi (tcohen) from comment #54)

(In reply to Paul Derscheid from comment #53)

...

Just ran the koha-qa on this. Is this a false positive?

It is just we need to teach the QA tools about `safe_url`. False positive.

I've only recently been learning about this. The built-in filter "xml" does the same thing, and I provided a patch for that on bug 21731. Would it be OK to just do the same here? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38214 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 --- Comment #57 from David Cook <dcook@prosentient.com.au> --- Created attachment 174101 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174101&action=edit Bug 22223: t::lib::QA::TemplateFilters missing built-in TT filter "safe_url" causes false warnings -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #170577|0 |1 is obsolete| | Attachment #174101|0 |1 is obsolete| | --- Comment #58 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 174104 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174104&action=edit Bug 22223: Add filter to make item URLs safe in template output This change adds a "safe_url" filter which takes a text input and returns a Perl URL object which stringifies to a safe URL. This change is only needed in the OPAC as the staff interface handles the item URL display using Javascript not Template Toolkit. 0. Apply patch and koha-plack --restart kohadev 1. Create an item for a record using the following URL https://koha-community.org?url=https%3A%2F%2Fkoha-community.org 2. Go to the OPAC for that record and verify that the URL is not double-escaped 3. Create a malicious payload (talk to QA/security team for this if necessary) 4. Note that the malicious payload is escaped 5. prove t/Koha/Plugins/SafeURL.t 6. Celebrate! Signed-off-by: Lucas Gass <lucas@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Version(s)| |24.11.00 released in| | Status|Passed QA |Pushed to main -- You are receiving this mail because: You are watching all bug changes.

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

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Lucas Gass (lukeg) <lucas@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223 Chris Rowlands <chris.rowlands6@nhs.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris.rowlands6@nhs.net -- You are receiving this mail because: You are watching all bug changes.