Item11498: Implement a new whitelist mechanism to help sanitize the script zone

See SecurityAlert-CVE-2012-1004 for important information about this task

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 script zone 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

-- PaulHarvey - 03 Feb 2012

See also: Support.SecurityAlert-CVE-2012-1004, and Item11501

-- PaulHarvey - 04 Feb 2012

Pushing this out into 1.2.

-- GeorgeClark - 01 Apr 2012

This is clearly and Enhancement, not a Release Blocker, so regrading.

-- CrawfordCurrie - 10 Mar 2014

Please create a feature proposal based on above findings. Work will be deferred to >1.2 to let it go without for now.

-- MichaelDaum - 02 Jun 2014

Commenting is disabled while not logged in