installation1Add my vote for this tag security2Remove my vote on this tag create new tag
, view all tags

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.

As TWiki does not currently attempt to prevent injection of client side script code (such as Javascript), installing TWiki on the same domain as web applications which store sensitive information client-side, poses a security threat for those other applications.

Examples of such web applications may include webmail, web hosting management systems, database management web applications, webftp. An example of an issue would be if a hacker injected JavaScript into a twiki page that accessed cookies on the client's computer that belonged to a webmail account on the same domain as the twiki - if the webmail saved its passwords in cookies, the JavaScript 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.

TWiki Authentication

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

TWikiAccessControls 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.

Large granularity

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.

Securing scripts

While it is immediately obvious that most TWiki users need access to view and edit, 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 statistics 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.

Securing attachments

See TWiki.TWikiAccessControl#SecuringAttachments

Contributors: CrawfordCurrie, SvenDowideit, PeterThoeny


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...

-- EricWoods - 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.

-- EricWoods - 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:

  1. 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.
  2. 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?
  3. How do I "require the use of ... Firefox or Opera"? I assume if I just ask nicely, then hackers can still use other browsers.
  4. 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.

-- EricWoods - 20 Feb 2007

The point is to establish an environment where a TWiki user can't easily leverage JavaScript to perform nasties on other applications. What they might use the JavaScript for 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.

There are of course other ways to block cross-scripting attacks, such as disabling JavaScript in TWiki topics, that all add to the security of your site.

-- CrawfordCurrie - 20 Feb 2007

Can i secure an individual page, or just a full web?

-- DanielKorel - 2012-07-05

Yes, see TWikiAccessControl.

-- PeterThoeny - 2012-07-05

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2012-07-05 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.