Foswiki Security Features

Overview

Because you can write to it using just a web browser, any wiki is potentially vulnerable to abuse from evil people. This abuse may take the form of SPAM, use of the site for phishing and cross-site scripting (XSS), or attacks on the site itself using eavesdropping, cross-site request forgery (CSRF), and code injection. Foswiki has a range of features designed to protect sites against exploits of these types.

Ultimately all security measures trade off security against usability and performance, and it's up to each site administrator to decide what features they need to defend their sites. A site behind a intranet firewall is likely to need a lot less protection than one in the open internet, for example. This guide is intended to help you understand what security features are available, and choose what features you need.

While the Foswiki developers have done as much as they can to protect Foswiki users while still providing a highly useable wiki, it is impossible to guarantee 100% security. There is always a risk that someone will find a new way to exploit a site, perhaps via a broken browser or broken web server, or a misunderstood or incomplete configuration. So administrators need to monitor security alerts, promptly apply security upgrades when they appear, and are requested to notify the Foswiki security team promptly as and when new threats emerge.

In the following descriptions, a string like this: {AntiSpam}{HideUserDetails} refers to a setting that can be set using Foswiki configure, and * Set SETTING refers to a configuration setting that can be set in your SitePreferences. Note that you may have to click "Yes, I have read all the documentation" in configure to be able to see all the options.

SPAM

There are two types of SPAM vulnerability that a wiki administrator needs to be aware of. The first is email harvesters, which scan your wiki for unprotected email addresses. These addresses are then included in email databases sold to unscrupulous people who want to sell you fake drugs or deposit large amounts of money in your bank account. Normally only public sites are open to being crawled this way.

The second type of spam is referred to as "wikispam", and usually consists of links to sites that are added to your wiki to increase their Google ranking. Usually only public sites are vulnerable to wikispam.

Configuring SPAM protection

1. Email harvesters
   1. Any email addresses shown by Foswiki include the {AntiSpam}{EmailPadding} string. This should be set to a non-empty string if your site is at risk of being harvested.
   2. {AntiSpam}{HideUserDetails} should always be set to prevent accidental leakage of user details via %USERINFO.
   3. If you don't want your site to be indexed by normal search engines, you can disable the {AntiSpam}{RobotsAreWelcome} setting. You should also read up on the crawler controls supported by your web server, such as robots.txt.
2. Wiki spam. Foswiki doesn't provide any defences against wikispam in the default distribution, but has two main solutions available for download by sites that need protection.
   • The AntiWikiSpamPlugin attempts to reduce the instance of Wiki Spam by using the MoinMoin AntiSpamGlobalSolution to detect that a page being saved contains spam. If it does, it refuses to save it. Because the plugin only operates when a topic is saved it is an extremely lightweight, but still highly effective, solution.
   • The BlackListPlugin further protects against excessive page access (e.g. by bad robots), and suspicious activities of users such as multiple registrations or rapid topic updates suggesting robot spam. The plugin monitors IP addresses and maintains banlists to choke suspicious users. Because this plugin operates on every page access it can impose a significant burden on a site, and should normally only be required by a few particularly vulnerable public sites.

Because google ranking relies on crawlers being able to visit your site to index it, a spammer will get no value from your site if you ban all robots. However a spammer will not know this, and may mount an attack anyway.

Phishing

Phishing in a wiki context usually refers to the use of your site to mislead users into thinking they are interacting with another site. For example, a Foswiki page could be crafted to look like the login page for a bank, or could be used redirect a user to an external site that prompts for login details. Phishing may also be used to try to get the login details of other wiki users. Phishing attacks are normally mounted against public sites, but sites behind firewalls also have to be careful. It may be possible for a disgruntled ex-employee to leave behind a "phishing bomb", or for an external third party to use a cross-scripting vulnerability to seed phishing code on your site.

Preventing use of your site for phishing generally means making it as awkward as possible to mount a phishing attack using Foswiki.

Configuring phishing prevention

Several Foswiki scripts support the idea of redirecting to a new URL after the task is complete. You can prevent redirection to a URL using the {AllowRedirectUrl} setting (you will still be able to redirect to another Foswiki page).

{INCLUDE}{AllowURLs} can be used to block %INCLUDE from being used with URLs. This prevents a phisher from including an external URL that replaces or compromises your Foswiki page.

Cross-site Scripting (XSS)

Cross-site scripting is the process of injecting malicious Javascript code into your wiki pages. The usual goal is to subvert the wiki to support some evil intentions, such as phishing or eavesdropping.

Obviously if you allow open registration to your wiki, and allow any user to add Javascript code to topics, you are issuing an open invitation to cross-site scripters. The most basic defensive steps are therefore to limit registration (for example, to colleagues in a corporation) and to disable Javascript in pages (see configure).

Because wikis often reflect the values of URL parameters back to the user (for example, you enter your name in a form, and on the next screen you see your name displayed in a topic) there is a risk that Javascript code could be passed in these URL parameters. This code would then be implanted in the outgoing page, and possibly used for evil. Foswiki defends against this by carefully filtering the values of input URL parameters to eliminate Javascript code from them.

Note that it isn't just public sites that are vulnerable to XSS. A site behind a firewall can still be attacked by an external agency, for example by using Javascript on an external site (see CSRF below) or by simply sending tainted links by email to people who have access.

Configuring XSS defences

By default Foswiki allows the authors to include inline scripts in their content, using the <script> HTML tag and the <literal> Foswiki tag. This is appropriate for sites where you trust your users, but public sites should definitely disable the {AllowInlineScript} setting to block this.

For the ultimate in XSS protection, the site admin can choose to install the SafeWikiPlugin. This plugin filters all output HTML to eliminate any dangerous Javascript from the body of the topic. Javascript can still be used, but only when it is read from a file on the originating server. The plugin can also filter external URLs.

Eavesdropping

Attacks such as man-in-the-middle can be used to watch the communications between a server and a client. This sort of attack can be used to find out passwords or other sensitive information.

Configuring eavesdropping defences

Eavesdropping defences rely on setting up your webserver correctly.

When Foswiki is configured to use Apache Login with Apache Basic Auth, and when it uses Template login, then passwords are sent in plain text. This means that passwords will be open to any eavesdropper. For this reason you are strongly recommended to configure your site so that passwords etc. are sent over HTTPS rather than simple HTTP.

The Apache documentation (or documentation for your other webserver) should describe how to set up HTTPS.

An alternative (available only with Apache Login) is to use 'Digest' authentication, which sends passwords encrypted.

Cross-site request forgery (CSRF)

Cross-site request forgery uses the fact that web servers have no simple way of confirming that a request comes from a known, reliable source. Typically a CSRF attack uses an external site which contains some Javascript code that interacts with your wiki. A user who is logged in to your wiki is seduced into opening a page on the external site. The act of opening the page executes the nasty Javascript, which uses the logged in user's ID to perform operations on the wiki as that user, without their knowledge. Cross-site request forgery can be used to mount any of the other attacks described here.

The dangers of cross-site request forgery are well documented. There have been some high profile cases where confidential information has been lost to criminals using this technique. Read the wikipedia article for more background. It's important to realise that CSRF doesn't just affect public sites. Any site behind a firewall is potentially vulnerable, because at the end of the day, it is the logged in user who does the attacker's work.

Foswiki includes protection against cross-site request forgery, as recommended by the Open Web Application Security Project (OWASP).

The Foswiki protection works on multiple levels. First, all requests which might change wiki content are required to be POST requests. This blocks the most common technique of embedding a malicious link in an HTML IMG tag. Second, all requests have to be identifiable as having come from an HTML page that was generated by the server. This is done using a technique called double submission, which involves embedding a validation code in the HTML forms in the page, and serving a secret cookie to the client browser as well. Any subsequent POST to the server has to be accompanied by a request code, which is composed by Javascript in the browser combining the validation code with the secret cookie. The same origin policy on the browser ensures that the secret cookie is only visible to Javascript running on a page that came from the wiki server, so this prevents Javascript that comes from an external site from generating a valid request code. If Foswiki sees a POST request that does not carry a valid request code, it prompts for interactive user validation of the request. This prompt is itself validated. Thus Foswiki prompts for user confirmation if it has any reason to be suspicious of an incoming request. This can be a bit of a pain sometimes, but the protection it offers makes it well worth it.

Because this algorithm relies on Javascript running in the browser, then browsers that disable JS will not be able to use a wiki which has this protection. This is common with most secure sites, such as banks. Also, because it relies on the "same origin" policy to block access to the cookie, then if a criminal is able to use cross-scripting on your wiki then they can also use CSRF, so it is essential that all the XSS protection described here is enabled.

Configuring CSRF protection

There is extensive help in configure (in the Security Sessions section when you show the Expert options) describing how to configure the 'strike one' CSRF protection described above. Sites that support users who disable Javascript will be unable to use this protection.

The full protection is only available in Foswiki 1.0.6 and above. Public sites using earlier Foswiki releases (and all TWiki releases up to at least 4.3.2) are strongly recommended to upgrade to Foswiki 1.0.6.

Code Injection

A common attack on websites is to pass code to be run on the server in carefully crafted URL parameters or topic content. This sort of attack is extremely dangerous, because if it is successful, it can result in your whole server being subverted.

Insecure web applications are often open to this sort of attack because they don't validate the values in such parameters adequately. There are various ways in which an external agent can get this code executed by the server; for example, the classic buffer overflow vulnerability that afflicted so many early web applications.

Because Foswiki is written in Perl, it has an additional vulnerability called 'eval'. This function allows the caller to execute code in a string within the web server, and if it isn't defended against is an easy way to crack a website. This vulnerability is shared with most other web languages, such as PHP.

The Foswiki core carefully validates all parameters to minimise the risk of active code attacks, and does not directly evaluate content stored in topics. However not all extensions are as careful, and administrators should be cautious of the risk of code injection via URL parameters passed to plugins.

Extensions

The Foswiki core developers have put a lot of work into protecting the code from the attacks described here. However the same strict standards are not applied to all plugins and extensions, and admins are recommended to audit any extensions they install for vulnerabilities of this type.

Some extensions, notably those that are most popular, are pretty safe. The ones to beware of are those that are not actively maintained, or run programs on the server, or are obviously poorly coded.

Older versions of Foswiki

For access to all the protection features described above, you have to be running the latest Foswiki version. Older versions may offer a subset of the features described above. Please refer to the release notes for the individual releases and, importantly, the release notes for following releases, to see what is and what is not included.

Additional Extensions

The following extensions offer significant improvements for site security. They are mainly applicable to public sites, and are not normally necessary behind corporate firewalls. However you are recommend to familiarise yourself with their capabilities.

• AntiWikiSpamPlugin
• BlackListPlugin
• SafeWikiPlugin

Refer to the documentation of the individual extensions for details on configuration.

Configuration in topics

The main security controls that are configurable from topics are the access controls. AccessControls contains detailed documentation on these options.