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