How can I secure my Foswiki against hostile attacks?

The first piece of advice is "Don't panic". Foswiki offers many advantages in productivity, collaboration, synergy, and creativity that makes it well worth the risk of the limited damage an attacker can inflict. By following the advice on this page, you can select the level of security that is appropriate to your site without compromising usability.

If you use all the countermeasures described here, Foswiki is one of the best protected collaboration tools available. Spammers will seek softer targets if they can't get into a site through their usual mechanical hacks. Even determined criminals can be foiled using a combination of web server and Foswiki security features. Of course no web site is guaranteed 100% secure, but you can easily make your site very difficult to crack.

Which measures should I take first? There is no simple answer to this question. You can start by asking "what sort of attack should I be concerned about?" And this more than anything else has to do with what type of information you keep on your Foswiki.

Identify your requirements

Is my Foswiki on the Internet or on an intranet behind a firewall?

Your first instinct is that an Internet site needs more security than an intranet site, but it is not as simple as that. In most cases, an Internet site does require additional protection, but you have to decide what you want to protect yourself against.

On the public Internet, common experience is that Wikispam is your greatest concern.

• Attackers will put URLs in all sorts of places to get their Google ranking up. They will typically target topics that are viewed on any page like WebTopBar, WebBottomBar, WebLeftBar, WebLeftBarWebsList, and WebLeftBarLogin.
• Attackers will target topics and webs that no one checks every day. The hidden _default and _empty webs are a common place for attacks.
• Attackers will attach questionable files to topics and use your site as storage.

Most Internet wikis do not carry confidential information, so it is not disclosure of sensitive information that is the normal concern. If you run a business, note that a wiki on the Internet is not the best place to hide confidential information. A wiki is, most of all, a collaboration platform that enables people to share and update information.

Do I store confidential information on my Foswiki?

Again, a wiki is designed to be a collaboration tool: the focus of a wiki is to enable people to find and update information easily. If you want to hide information and limit access to a select few, a wiki may not be the right tool in the first place. Having said that, if cotrolled access is one of your requirements, then Foswiki is one of the best tools for the job.

There are more security classifications than "confidential" and "public": Information like the list of employees that will be laid off next month does not really belong to a wiki or any other web-based tool for that matter. A project status report, on the other hand, though not public, is less critical to keep restricted. Foswiki can protect against casual access to this type of information with a reasonable amount of protection.

Remember that most confidential information is not leaked through insecure websites, but via email. Don't neglect to instruct your users on the safe handling of information in all formats - you may get more value this way, than by trying to secure every last byte of data on your internal web sites.

How do people register on my Foswiki? Do I know who they are?

Foswiki and most wikis work by soft security. A wiki does not function well if you use it as a content management system with limited access. To release the power and potential of the wiki principle, you need to allow anyone to see and edit everything by default, locking only specific topics as needed.

Soft security works by these principles.

• You cannot destroy anything in a way that cannot be easily restored. All versions of all topics are stored and you can always roll back to any revision, reverting any vandalism or other bad changes (deliberate or accidental).
• We know who you are. We know what you did and when you did it.
• Community responsibility: You are part of something your peers have created. It is not the masses against an authority: It is you against your peers. Peer pressure and community encouragement/coercion serve to keep contributors honest.

To implement these principles, the following is required:

• No one can post anything anonymously.
• No one can register under a false identity.

And this is the challenge! On a public Internet site anyone can register with a disposable email address. You do not know who your users are, which makes it difficult to rely upon the principle of community responsibility. If this principle is important for your site, then you should disable registration and only let an administrator add trusted users.

On an intranet the best way is to implement a single signon scheme, such as LDAP, so that people can only login if they already have an account on the central user authentication system. You can still use Foswiki registration to map a corporate login name to a friendly wiki name. The important thing is that you can always see which login corresponds to which wiki name. This ensures that no one can edit anything on the wiki anonymously.

The single most important security measure — on both intranet and public web sites — is to disable anonymous editing.

Which extensions do I need to use?

The core Foswiki product, including the extensions bundled with the basic distribution, is maintained by many developers. Other extensions are normally maintained by one to two developers.

Extensions can enhance security, but they may also open up security holes. If you are concerned, look carefully at open bug reports in the Tasks web at foswiki.org. Look carefully at what the extension does. Ask members of the Foswiki community on IRC, on the Foswiki Support web, or the foswiki-discuss mailing list for advice.

Recommended approaches

Now that you have a better understanding of your requirements, here are various approaches we recommend:

Subscribe to the foswiki-announce mailing list

If security issues come up you will hear about it the minute we have a solution for it. See MailingLists for more information.

Do not modify the distributed templates and System web topics

When a security issue is raised you want to be able to upgrade fast.

If you have made too many alterations, upgrading will be a pain. Follow the instructions in PatternSkin that tells you how to tailor the skin by adding additional templates and CSS files that will not be overwritten in an upgrade.

Always define extension settings in Main.SitePreferences instead of the extension page in System web.

Do not use the Main web for content

To make it easier to upgrade, the best approach for a new installation is to create a new web to hold your wiki's content. The Main web is used by Foswiki for user topics, group definitions, and site configuration. By placing your content in a different web, you will avoid any potential for conflicts with user names, group names, or configuration topics. Alternatively, you can set it up so that new users have to go through a moderation process before they can post.

Prevent anonymous registration

• In an intranet site use the single signon deployed by your company. For LDAP you can use ApacheLogin with a simple Apache configuration that requires access to a selection of the bin scripts to be authenticated using the central LDAP server. For more advanced use you can install LdapContrib.
• In a public internet site you can disable registration or require that each registered user gets approved so only trusted people are added.
• The AntiWikiSpamPlugin can block registrations from email domains that are known sources of spam.

Limit the information collected during registration

The registration form fields, Organization, Organization URL, Comment, etc. are a way for a spammer to insert links into their user topic during the registration process.Another option is to restrict view of user topics. If the spammer cannot insert publicly viewable links into the topics, they are of less interest.

Use a KnownWikiGroup

A fairly easy-to-manage workaround (originally proposed by Harald Joerg) to full-blown registration approval is as follows:

1. Create a group, say KnownWikiGroup, via the usual mechanism (in Main.WikiGroups on your site)
   • Lock down edit privileges on it to you and/or your AdminGroup (or equivalent).
2. If your site already has users, populate the group with a list from the WikiUsers topic.
   • You may want to vet this list for wiki spammers.
3. Edit the WebPreferences of every web on your install, adding * Set ALLOWWEBCHANGE = Main.KnownWikiGroup (also ALLOWWEBRENAME)
   • Do this also for the _default web; spammers have been known to hide content in there. Also, if you lock down the _default web, all webs you create thereafter will be automatically protected.
4. Modify the email templates and registration topic to indicate that any new registrants have no write/edit access, and should contact you or the webmaster (or whoever) for manual approval to get write/edit privileges.

This approach can work for moderate size installations (with a few hundreds of users) but might not scale well on extremely busy sites.

Configure the web server to protect attachments

By default, attachments to topics are stored in a web-accessible directory tree. This is a deliberate choice to allow URL references to attachments to be served as fast as the webserver can support. However there are risks associated with this on some webservers. Apache should be configured so that AllowOverride None applies throughout the pub directory tree. Also, any SetHandler/AddType calls in the web server configuration should be reviewed to ensure they don't enable the execution of scripts stored in the pub area.

Enable access controls for attachments

By default the attached files to topics are not protected against viewing. This is a deliberate design choice to maximise performance. It is much faster to serve attachments directly from the web server than serving each file through a perl script.

To make your installation more secure, you can enable access controls for attachments, with the option of excluding specific file types for performance reasons. See ApacheConfigGenerator.

Police the site

Especially when registration is not controlled, you need to train your users to regularly police the site. Make sure you enable the WebNotify feature and register yourself to receive updates so you can follow the pages that get altered. You do not need to check everything, but be on the lookout for new users and changes they make.

Use the System.SiteChanges topic regularly to look for topic changes that are from new users. Check what they are doing. Try not to scare them off — they are not all evil; sometimes they just make beginner mistakes.

Rapidly remove spammers from the site. The AntiWikiSpamPlugin provides a tool for removing user accounts.

Choose a secure configuration.

You should read all the available advice on hardening your web server against potential attacks. At the very least, you should ensure that configure is only accessible to people who need to use it, and that a password is set.

In configure these settings are especially important.

• {Register}{NeedVerification} — Enable this for public internet sites. Keep in mind that this is a very low barrier though as there are many services that provide disposable email addresses.
• {Register}{EnableNewUserRegistration} — lets you to disable new users from registering. You can enable it and register users manually if you want to make sure who has access. In a small company with 1-100 employees this may be a good way to control access.
• {DenyDotDotInclude} — never disable this setting.
• {INCLUDE}{AllowURLs} — enables including other webpages in a Foswiki site. Never enable this on a public Internet site. And on an intranet site behind firewall only enable it if you really need it. You do not need this enabled to INCLUDE topics within same Foswiki site. Enabling this setting can leave your installation vulnerable to cross-site request forgery attacks, and because the included web page is retrieved by the Foswiki server, it may bypass authentication steps on the included site.
• {AllowInlineScript} — can protect against some evil scripts but can also cause trouble for some extensions. SafeWikiPlugin does a more thorough job of blocking potentially dangerous HTML to protect against your site being used to host cross-site scripting attacks.
• {AllowRedirectUrl} — should be disabled unless you really need it. With this feature enabled an attacker can plant some evil code that redirects you to another URL. The attacker can then lure someone to enter their username and password on a site that looks like your Foswiki and record it for later abuse.
• {Validation}{Method} — should be set to strikeone. Also review the other {Validation} settings. Configure help provides some guidance on their use.
• {Htpasswd}{Encoding} — should be set to something other than crypt which truncates passwords at 8 characters. Enable the {Htpasswd}{AutoDetect} feature, and change the encoding to something more secure.

Also, new in Foswiki 1.1.5

• {Register}{UniqueEmail} — can prevent multiple registrations using the same email address.
• {Register}{EmailFilter} — will do a simple regular expression filter against the email address.

Review security of Extensions

Non-core extensions often make compromises between security and performance. What is acceptable on an internal wiki may not be appropriate for a public wiki. Don't just "Accept the defaults" after installing an extension. Carefully review the settings and disable features that might have security implications.

Use SafeWikiPlugin

Because Foswiki supports the embedding of raw HTML in topics, it is vulnerable to attacks that involve JavaScript planted in a topic. If this is a concern for you, install the SafeWikiPlugin which filters out any JavaScript that an attacker plants in a Foswiki topic. Of course this will also block honest users from using JavaScript inside topics.

But before you panic and install this plugin, evaluate what kind of site you have. If you have full control over your users and do not allow anonymous registration or anonymous editing, an attack by planting evil JavaScript can never be launched without leaving a trail. The attacker has to plant the code in a topic and to do that the evil-doer must login and save the topic. (Even if the code is later removed, the history trail is still present.) In a corporate environment, anyone doing this would be at risk of being fired and so a deliberate attack is highly unlikely. Remember that wikis work mainly through soft security.

If your site contains confidential information that must be safeguarded against access by unauthorized personnel at all costs, then the SafeWikiPlugin provides additional countermeasure against attacks, as well as guarding against attacks against other intranet sites being hosted by your Foswiki installation.

Note for developers: extensions can still use JavaScript by adding it to the head section of the document.

Avoid logging in as an administrator unless you have to

The normal approach of most administrators is to add themselves to the AdminGroup. This may be an entirely reasonable approach in a trusted environment where accidental changes to content and configuration values is a bigger concern than vandalism or security concerns. On the Internet, however, an attacker will try to become admin to plant spam. Logging in as admin for extended periods of time leaves you very vulnerable to cross-site scripting attacks.

To avoid logging in with administrative powers unless absolutely necessary, create two logins for you to use: one for everyday use, and one who is a member of AdminGroup. (When integrating with a centralized authentication mechanism, this may require two separate identities in the central database.) Login as an administrator only when you need to perform a specific privileged task, and log out immediately afterwards.

Another simple solution. Instead of adding yourself to the AdminGroup, add your name to the ALLOWTOPICCHANGE setting of the AdminGroup. This way you can easily add and remove yourself from the AdminGroup instead of remaining a permanent member of the group. See ImplementAddMeToAdminButton for an even simpler technique. (This will be a feature in foswiki 1.2, but is a simple INCLUDE topic which can be used in any 1.1.x system.)

You can also use the special internal admin login (see AdminGroup) if you are the only administrator and are also managing the site's configuration values and extensions via the web-based configure tool. However if these roles are separate, then this approach cannot be followed.

Use an antispam plugin

On a public Internet site with open registration it is only a matter of time before you will be spammed. There are two extensions available that help prevent people from saving topics containing spam:

• AntiWikiSpamPlugin — prevents saving topics containing URLs from a common antispam list which is regularly updated
• BlackListPlugin — does the same as AntiWikiSpamPlugin plus it has some features that blacklists IP addresses that have uploaded spam or has generated too heavy traffic on a site.

Use Anti-virus protection

The Extensions.ClamAVScanPlugin can scan attachments and block upload if threats are encountered. In addition to common virus threats, ClamAV can be configured to match and block common risks like credit card numbers, and US Social Security numbers contained in attachments.

Disable editing in System, _default, _empty, and Trash webs

It is recommended that only administrators can edit these webs.

Spammers love to hide their spam in the webs that are rarely checked, such as Sandbox and Trash, or in the topics that are part of any page view, such as the left bar.

Backup your Foswiki daily

And the most obvious preventative measure: Backup your Foswiki site every day.

Use a backup scheme where separate backup copies are kept over a period of time, without overwriting the most recent copies. An attack may not be found until weeks after, so you need backups covering several weeks in the past.

Keeping regular backups will also guard against hardware failures.

See also: How do I backup a Foswiki installation?, SecurityFeatures for more detail on Foswiki security features, and how they work.

Keep your Foswiki installation up to date

Security issues are often discovered and fixed with little fanfare. By staying up-to-date with foswiki, you'll have the benefit of the latest fixes. Also whenever a CVE is announced, apply the hot-fix as soon as practical.