[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Koha-devel] Re: XSS Vulnerabilities in Koha
From: |
Chris Cormack |
Subject: |
[Koha-devel] Re: XSS Vulnerabilities in Koha |
Date: |
Thu, 30 Aug 2007 21:57:41 +1200 |
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 address@hidden
VP Research and Development www.liblime.com
LibLime +64 21 542 131