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

[bugzilla-daemon at bugs.koha-community.org]

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

--- Comment #7 from David Cook <dcook at prosentient.com.au> ---
I just removed the "url" filter from [% ITEM_RESULT.uri | url %], and I was
able to exploit the XSS vulnerability by putting a malicious string into the
"952$u" subfield via the Staff Client...

Looking at https://www.owasp.org/index.php/Cross-site_Scripting_(XSS), it talks
about how XSS occurs "anywhere a web application uses input from a user within
the output it generates without validating or encoding it". 

In the case of ITEM_RESULT.uri, I don't think that encoding it is the right
solution. However, we could validate it by writing a custom Template::Toolkit
filter to use Perl's URI module to ensure that it is actually a URL? 

Trying to think about a valid URL that could also include a malicious
payload...

--

I just took a malicious string (perhaps best I don't share it publicly?) that
exploits [% ITEM_RESULT.uri %] and put it through URI->new() and it escaped the
malicious characters, which is good.

I just put "https://idp.com?redirect_url=https%3A%2F%2Fsomewhere_else.com"
through URI->new() and it didn't modify it in any way, which is good.

I just put "http://loris.example.org/loris/1234%2F5678%2F90123.tif/info.json"
through URI->new() and it didn't modify it in any way, which is good. 

I just put "https://idp.com?redirect_url=https://somewhere_else.com" through
URI->new() and it didn't modify it in any way, which is fine.

-- 
You are receiving this mail because:
You are watching all bug changes.