Securing your TWiki
This topic is intended to help administrators understand the security risks associated with TWiki, and suggest ways in which those risks can be minimised. There are a number of important aspects to TWiki security.
General Website Security
TWiki is not
designed to be a security layer on your website. It is your
responsibility to make sure your websites are secure enough from intruders. Do not
rely on TWiki security to provide adequate protection for valuable data. Work on the basis that anyone who can edit
a TWiki topic could potentially damage your website, and ensure controls are in place to constrain the possible damage they could do. This extends to careful management of access permissions, virus scanning, etc.
could read out the password and send it back to the hacker.
To work around this problem, admins can setup TWiki on a different domain than the other web applications, and require the use of web browsers which support client side domain scripting context separation, such as Mozilla Firefox or Opera.
The following advice from TWikiUserAuthentication
is reproduced here in the expectation that it will be extended/improved upon:
At one extreme, the most secure method is to use TWiki via SSL (Secure Sockets Layer), with a login manager installed and Client Sessions turned off
Using TWiki with sessions turned off is a pain, though, as with all the login managers there are occasions where TWiki will forget who you are. The best user experience is achieved with sessions turned on
As soon as you allow the server to maintain information about a logged-in user, you open a door to potential attacks. There are a variety of ways a malicious user can pervert TWiki to obtain another users session ID, the most common of which is known as a cross-site scripting
attack. Once a hacker has an SID they can pretend to be that user.
To help prevent these sorts of attacks, TWiki supports IP matching
, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.
Session IDs are usually stored by TWiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So TWiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in TWiki pages to include the session ID in the URL.
The first method works well as long as IP addresses are unique
to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method
If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".
Most TWiki sites don't use SSL, so, as is the case with most
sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
Finally, it would be really neat if someone was to work out how to use certificates to identify users.....
TWiki User Access Controls
describes how to use TWiki access controls, but it doesn't say much about when
you should use them. Access controls in any environment are a mixed blessing. Loose access controls increase the risk of exposing data to an unintended audience. Tight access controls stifle collaboration.
Use the minimum controls possible
The best way to approach access controls is to apply the minimum
access controls you can, while still satisfying the corporate wienies. Normally you will restrict on the basis of some organisational constraint - for example, a project. Whenever access controls are applied in this kind of context, if you are not allowed others to read, make sure the area is matched by a parallel unrestricted
area where the unworthy can feel that they are contributing to the same topic. otherwise you risk shutting out new thought.
Another aspect of minimum
access controls is to apply the controls to the largest
granularity you can; i.e. restrict at the web level, rather than the topic level. It is much easier to manage large grain access controls, and it maximises the set of people who share the same level of access.
Work on the basis of "secure only if necessary"
Many companies apply access controls to every last item of data. Data should of course be classified according to it's required controls. However most companies over-classify
data. It may be appropriate to classify next year's takeover plans as secrets, but not next year's canteen menu.
The best principle to apply here is that data should always be easier to classify at lower levels of control, and progressively harder to classify at higher levels. There is always a risk that you will under-classify some data, but frankly, it's a much lower risk than treating your staff like mushrooms.
A good compromise is to organise data into fairly large chunks; TWiki webs are good for this. Organising data into webs also lets you use a tool like WebPermissionsPlugin
to simplify permissions management.
While it is immediately obvious that most TWiki users need access to
, it's not that obvious for the other scripts. If you want TWiki access controls to be effective, you have to bear in mind that there is a small risk that certain TWiki scripts will give away information about your content. For example, the
script is designed to be run from either a cron job, or from the browser. When run from the browser, it reports the top topics; and the name of a top topic could give an intruder (or even a colleague!) useful information.
Your general policy should be to consider each of the top-level TWiki scripts, and restrict access to scripts wherever possible. Consider, for example, if your users really
need to be able to rename/delete topics, or whether that can only be done by reference to an admin or project lead. Use the webserver to constrain access to scripts to specific users.
It would have been nice to know that TWiki should be installed on its own domain at the start of the installation instructions, rather than after I have got everything installed...
- 04 Feb 2007
In the "General Website Security" section near the top of the page, it mentions security holes, but that "To work around this problem, admins can setup TWiki on a different domain than the other web applications, and require the use of web browsers which support client side domain scripting context separation, such as Mozilla Firefox or Opera."
I have some questions about this, that I have posted a support page on here SecurityWithSubdomainVsDomain
- 06 Feb 2007
Unfortunately, my support request on SecurityWithSubdomainVsDomain
has not turned up any solid answers yet.
My questions about "domains..." and "client side domain scripting" are:
- Would it be sufficient security to setup TWiki on a different subdomain (e.g. www.sub.domain.com) instead of on a different domain? I am hosted by 1and1 so can do this, and it is implemented as a virtual host in the httpd.conf.
- Even new domains I create are all located on the same host (e.g. www.abcd.com maps to .../clients/abcd and www.efgh.com maps to ../clients/efgh). So if I create a new domain for my TWiki, is it actually going to offer any added security?
- How do I "require the use of ... Firefox or Opera"? I assume if I just ask nicely, then hackers can still use other browsers.
- Maybe I don;t understand the security risk properly. Is this 'just' a risk to the user of having their username and password stolen? Or could a hacker gain someone else's (e.g. the admin's) un and pw and gain control of the wiki? Or could a hacker gain access to my server and extract or modify data in other web applications? How could a hacker do this - could you please link to more info on this.
- 20 Feb 2007
is rather beyond the scope of this discussion, though it's easy to imagine a phishing attack based in a wiki. Say you had a wiki at http://worldbank.com/twiki/bin/view
. That domain is obviously rather convincing, so a phishing attack from within the TWiki that was able to leverage the domain name would be more convincing than the average. Another possible attack (described in the text above) involves the raking of cookies from other applications in the same domain. Of course any site that stores sensitive information in cookies is asking for trouble, but there is no point in making this sort of exploit easy
. i honestly don't know if being in a subdomain makes any difference to this vector.
- 20 Feb 2007
Can i secure an individual page, or just a full web?
Yes, see TWikiAccessControl