[moved to Koha-devel] ... Chris Cormack wrote:
We did fix this up a while back for the opac, but overtime vulnerabilities might have crept back in. I'm not too worried about the intranet side, if someone malicious has access to that, you have bigger problems than xss :-) But Id certainly like to see patches for the opac.
Correct me if I am wrong, but XSS does not require the attacker to have access to your server. Just the ability to carefully construct a URL to that server that allows an attack via a (naive) user on the server, the Intranet in this case. If one is already logged into the Intranet and then is somehow tricked into clicking on a malicious (XSS) link found elsewhere, in an email or on another site, bingo! Gotcha! I certainly do not profess to be an expert in XSS, but I'd imagine that if one was determined enough to get access to the Koha Intranet of a particular library for some nefarious purpose, a cookie theft might be possible. It would be educational to see an XSS in action on Koha, a real world example. Then more eyes could have a look and help with an XSS audit. My brief read on the web about XSS indicates that there are many many varieties of the exploit, so that one would have to keep in mind these many attack vectors while reviewing the sourcecode. And it would seem that many attacks originate in user-supplied form data, so that proper escaping and entity replacement of significant delimiters like < and > are paramount as a first level of defense. Which brings to mind another audit: one for SQL injection attacks. I haven't had a close at the code, but a grep of "->quote(" turns up 102 uses in Koha/2.2.9, which leaves one feeling somewhat confident that the problem has been addressed at one stage. cheers rickw -- _________________________________ Rick Welykochy || Praxis Services I didn't have time to write a short letter, so I wrote a long one instead. -- Mark Twain