https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22223
--- Comment #7 from David Cook <[email protected]> --- 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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
