Session Riding and multiple XSS in WebCit
Vendor contacted: 2007-06-24
Affects: Webcit < 7.11
Fixed: 2007-07-06 (WebCit 7.11)
1. Background
WebCit is the webfrontend to administer and use Citadel, which is an
open-source groupware server.
2. Session Riding
2.I. Problem Description
It is possible for an attacker to execute actions in the name of a
victim, simply by having him visit a website the attacker controls
content on. There are no precautions to prevent Session Riding at all.
2.II. Impact
All userdetails, preferences and settings can be modified by an attacker
in whatever he likes to. It is also possible to create new rooms, tasks,
responses and pretty much everything else too in the name of the victim.
2.III. Solution
I would recommend to use nonces that uniquely identify every action and
are checked when the action is executed.
For the change of the password I would additionally recommend to require
the old one before being able to change it.
3. Stored Cross-Site-Scripting
3.I. Problem Description
At several locations the user given input does not get properly
sanitized and thus enables Cross-Site-Scripting.
3.II. Impact
In the calender mode entries can be viewed by holding the mouse over it.
The user input displayed in the onmouseover window does not get sanitized.
When in "Bulletin Board" mode the content of an entry does not get
sanitized properly and may contain malicious javascript.
If the preferences contain a "> it is possible to break out of the value
attribute of the input field. At first glance this does not seem too
evil, since this entries are made by the users themselves, but due to
the fact that the preferences may be set by an attacker utilizing the
possibility of Session Riding.
Room names are not sanitized properly too, when displayed on the room
page itself.
Because the name of a file, that gets uploaded is not changed by the
application and the filename is not escaped when displaying, it is
possible to include html or javascript code into the filename.
Possibly some other places I did not see yet.
3.IV. Solution
As far as i can see, the only thing you have to do is to apply the
existing filters to sanitize the situations above.
4. Reflected Cross-Site-Scripting
4.I. Problem Description
In the context of viewing a user the username may be chosen by the who
parameter. By using a specially crafted username it is possible to
inject html and javascript into the page.
4.II. Impact
There are several scenarios how this behavior may be used in favor of an
attacker. A pretty good diorama is, that an attacker sets up a website
which contains an invisible iframe that loads a Webcit page, the user,
that visits the attackers website, is logged in to. The loaded Webcit
URL looks similar to the proof of concept below, but contains possibly
more malicious javascript code, that enables the attacker to execute
arbitrary actions in the name of the victim.
4.II.5. Proof of Concept
Request
showuser?who=%3Cscript%3Ealert('xss')%3C/script%3E
4.III. Workaround
Do not echo the username given by the who parameter on the page.
4.IV. Solution
Escape the username within the h1 tag the same way as it is done in the
"send a message" link below.
Greetings,
Christopher Schwardt
The CInsects-Team