[Koha-bugs] [Bug 22223] Item url double-encode when parameter is an encoded URL

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Feb 28 04:42:14 CET 2019


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223

--- Comment #6 from David Cook <dcook at 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.


More information about the Koha-bugs mailing list