[prev in list] [next in list] [prev in thread] [next in thread] 

List:       unisog
Subject:    [unisog] Wiki security pointers for higher ed environment
From:       fw () deneb ! enyo ! de (Florian Weimer)
Date:       2005-06-18 11:33:04
Message-ID: 87aclnkihb.fsf () deneb ! enyo ! de
[Download RAW message or body]

* Gary Flynn:

> Anyone have any security oriented advice for
> setting up a Wiki in an higher ed environment?

There are two aspects of Wiki security:

  1. How does the Wiki software protect against attackers who try to
     gain control of the host running the software?

I think it's fair to say that the Wiki software I investigated so far
hasn't been written with security in mind.  The programmers were quite
careless when constructing file names, SQL statements or shell
commands, potentially leading to directory traversal and command
insertion attacks.

I tried to address this situation for TWiki, see my patch at:

  <http://www.enyo.de/fw/security/notes/twiki-robustness.html>

The main focus was shell command injection, but directory traversal
attacks should be stopped as well.  (TWiki doesn't use SQL.)  However,
you still have to be careful when using plugins, and my patch doesn't
deal with the second security aspects.


  2. How does the Wiki software enforce its own access control
     mechanisms?

For example, most Wikis provide some means to block a page against
edits or viewing by ordinary users.  In my experience, these
restrictions are easily circumvented.  Some Wikis allow uploading
arbitrary HTML content, directly leading to cross-site scripting
attacks.  I'm pretty sure no Wiki whatsoever protects against
cross-site request forgery (aka CSRF, "session riding").  In this
scenario, an attacker would lure some privileged user to web content
under his control, and use JavaScript (or plain hyperlinks, for
example in images) to access supposedly restricted Wiki content with
the victim's credentials.  (Apart from that, TWiki may fail to enforce
access controls in other, more mundane ways.)

The CSRF problem is a very hard one, which in some way or other
affects all web application.  Some people think that this is purely a
web application vulnerability.  I tend to view it in a more broader
context: In web browsers, content from different trust domains can be
mixed freely (there's no firewall, so to speak).  Web applications
have become a dangerous monoculture in which diseases can spread
easily from one carrier to another.


So the Wiki security situation is a bit disappointing.  If you don't
care about the second issue, you can pick any reasonably robust
implementation (I'm a bit skeptical about TWiki because development
has come to halt).  If you want to put sensitive data into your Wiki
and restrict access to it, you're out of luck.

[prev in list] [next in list] [prev in thread] [next in thread]