[Koha-devel] Re: XSS Vulnerabilities in Koha

[Chris Cormack]

On 30/08/2007, at 9:47 PM, Rick Welykochy wrote:

> [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.
>
Yep you might be able to do that, but all you would get is an md5  
string, we have just rewritten the authentication module using  
CGI::Session for 3.0.
And it wouldn't be any use to you, unless you were also spoofing the  
ip of the of machine that created that particular session.
Nothing of interest is stored in the cookie anymore.

What would be more nefarious is to craft a url so that someone thinks  
they are logging into koha, but instead are logging in to your site.  
The standard phishing scheme that I seem to get at least 5 emails of  
each day :)

> 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.
>
Yep, I'm all for that, Id encourage people to look at the code in git  
though and work on that.

> 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.
>
Yep, if quote isn't used place holders (?) are, which achieves the  
same thing.

Chris
--
Chris Cormack                            chris.cormack at liblime.com
VP Research and Development                        www.liblime.com
LibLime                                             +64 21 542 131