Background

A fundamental feature of Foswiki, and its ancestor, has always been the ability for users to turn ordinary wiki topics into powerful applications without the need to consult a programmer, or systems administrator, or indeed to touch any server-side stuff at all. Empowering ordinary users to do sophisticated things for their team or group is a core ideal in the wiki philosophy.

To that end, Foswiki is entirely permissive in what it will allow to be entered (or rendered) on a page. So any markup at all, including <script> tags, may be used without restriction.

Problem

All this makes Foswiki both a powerful enabler for ordinary users, and also an easy XSS target. Traditional thinking has been that, if you have gained permission to edit the wiki to set up these XSS pages in the first place, you've got bigger problems.

But this thinking glosses over some simple truths:

Some installations do not moderate the registration of new users. Out-of-the box Foswikis do not restrict CHANGE permission in the Sandbox and Main webs.

Some installations remove the rest script from the {AuthScripts} configure setting, and it's possible a plugin may offer a REST handler which does not require authentication. So if there are webs with unrestricted CHANGE permission, it may be possible (via a plugin) to add content to them without even being authenticated.

Even if webs restrict CHANGE permission, newly registered users on an out-of-the-box Foswiki can still edit their own user topic, unless you adjust the NewUserTemplate to prevent that.

Even if the NewUserTemplate restricts the newly registered user from editing their own user topic, they can still add arbitrary content via the formfields they filled when registering; so the NewUserTemplate had better restrict VIEW permission too, to shield others from potentially malicious user topics.

Solution

An initial solution being explored, is to resurrect the experimental SafeWikiPlugin, which was intended to address this very issue. However, it was written prior to the powerful new zones feature, so there is some work which needs to be done (zone whitelist mechanism) in Foswiki's core code.

We believe we can substantially improve the security situation as it pertains to arbitrary <script>, without completely crippling one of Foswiki's fundamental selling points. The current plan is as follows:

Disallow all on* HTML attributes (these allow JS code in their values). That means updating the current strikeone implementation

Make the scriptzone the only part of an HTML page which is allowed to contain <script> tags. That means no more in-line <script> tags unless it's via an ADDTOZONE{"script" ...} call or its perl equivalent

The ADDTOZONE feature will not add any content to the script zone unless it originates from a topic which is in the whitelist We currently envisage a mixture of a new $Foswiki::cfg{} configure setting (LocalSite.cfg) and FINALPREFERENCES style preferences

Finally, these new policies will take some time to adopt (Eg. converting all in-line <script> markup into whitelisted ADDTOZONE calls). So, we will ship a $Foswiki::cfg{} configure setting (LocalSite.cfg) which disables these policies for those sites which need more time to adapt. We also need good logging & diagnostic info in Eg. HTML comments to help Foswiki users in transitioning their plugins, wiki-apps, etc. to work with the new script policy