Security Alert: Foswiki Page View Cross-Site Request Forgery (CSRF)

Foswiki versions 1.0.5 is protected against the most basic CSRF attacks where simple HTML tags can alter content.

Foswiki versions 1.0.6 and later contain a major security enhancement, protecting against Cross-Site Request Forgery. The extra safe "double submit" algorithm, as recommended by the Open Web Application Security Project (OWASP) project has been used.

Attack Vectors

Prior to version 1.0.5, Foswiki allows HTTP GET requests to modify pages, allowing for Cross-Site Request Forgery attacks to occur by simply viewing a malicious page that uses this exploit. As with all cross-site request forgery attacks, the user viewing the malicious page must be already logged into the Foswiki installation in order for the attack to succeed. The Foswiki installation itself can be used to host the attack code, which increases the chance that the potential victim is already logged in.

Any HTML tag that triggers a browser to automatically access an URL can be crafted and added to a malicious page that will update a Foswiki web site with the content specified in the URL, using the identity of the user viewing the page. Examples of HTML tags that can be used for this exploit include <img>, <script>, <iframe>, and <obj> tags. An <a> element can also be used, though the user must follow the link in order for the attack to occur.

Impact

Using this vulnerability, an exploit can perform any operation while assuming the identity of the victim. This includes changing access permissions to Foswiki pages, or modifying the definition of access groups, including the Foswiki AdminGroup. Lower-privileged Foswiki users can insert the attack into a commonly visited page and thus elevate their access to that of the users visiting the page. The attack is transparent to victims (the victim's browser may display indications that it is accessing the network for an unexpected period of time).

Details

The exploit takes advantage of Foswiki allowing data to be saved/modified by a browser sending an HTTP GET request, which includes accesses via an <img>, <script>, <iframe>, <obj>, or <a> element.

Examples

Edit a topic using an image tag

<img src="/bin/save/Sandbox/TestTopic?text=Evil text" alt="" />

Edit user configuration using an image tag:

<img src="/bin/save/Main/WikiGuest?text=3y3%2520have%2520been%25200wn3d%2520by
%2520ashcrow%250A%250a---%252B%252B%2520Related%2520Topics%250A%250A%2520%2520%2520
%252A%2520Set%2520ALLOWTOPICCHANGE%2520=%2520Main.WikiGuest%252C%2520%
USERSWEB%.WikiUsers" alt="" />

Modify table cell

Note that the view operation can be attacked as well, as some extensions save data when view operations are performed. For example, EditTablePlugin can be exploited to alter the contents of a table cell:

<img src="/bin/viewauth/Myweb/TopicWithEditTable?ettablenr=1;
etcell2x2=New_value;etrows=5;etsave=Save%20table" alt="" />

Edit a topic using a hypertext link

Simple HTML anchor tags can be used to save data. Unless users inspect a target URL before following the link, they will not be aware that data will be modified by following the link, using their identity.

<a href="http://some.foswiki.site/bin/save/Myweb/TargetTopic?text=TheTextWeWantSaved">
Innocent looking text</a>

Resolution in 1.0.5

To prevent Foswiki sites from being vulnerable to silent attacks using image tags or other tags that cause the browser to initiate HTTP GET requests, and attacks by following hypertext links, the Foswiki team has restricted the ability to save data to HTTP POST requests. The Foswiki core and all extensions that are bundled with the basic Foswiki distribution have been altered so that no data can be saved unless the change is submitted using an HTTP POST request (typically via an HTTP form).

This affects any Foswiki applications that depended on using the GET method to modify data. Examples of applications that may need to be modified include the following:

• If you have implemented an application that creates new topics or changes existing topics using an HTML form, you must explicitly specify method="post" in the attributes for the form. Note the default value for the method attribute is get, so if no method attribute is specified, then the form will be unable to modify data.

• If you have implemented an application that generates links to the Foswiki save or view scripts, you will need to alter this application to instead display HTML forms with a submit button.

Further security enhancements in 1.0.6

Foswiki versions 1.0.6 and later contain a major security enhancement, protecting against Cross-Site Request Forgery using HTTP POST requests. The extra safe "double submit" algorithm, as recommended by the Open Web Application Security Project (OWASP) project has been used. This is the same algorithm used by several major banks and other security-conscious institutions, and requires that users have Javascript enabled.

Countermeasures

To protect your Foswiki installation, upgrade to the latest production release 1.0.6 or later.

Releaes 1.0.6 is available as an upgrade package that can be applied to a Foswiki installation running any version from 1.0.0 to 1.0.5.

Authors and Credits

• Steve 'Ashcrow' Milner and Richard Monk of Red Hat Infosec Team for disclosing the issue
• CrawfordCurrie and KennethLavrsen for contributing to the fix, the 1.0.5 and 1.0.6 releases and advisory
• Members of the Foswiki security team for discussions and ideas, for testing the 1.0.5 beta, for testing the new 1.0.6 "double submit" code and for editing this security advice

Action Plan with Timeline

#	Action	Date/ Deadline	Status	Who
1.	User discloses issue to foswiki security mailing list	2009-04-15	Done	Steve 'Ashcrow' Milner (Red Hat)
2.	Developer verifies issue	2009-04-16	Done	Crawford Currie
3.	Security team triage the issue	2009-04-16	Done	Kenneth Lavrsen
4.	Developer fixes code	2009-04-16	Done	Crawford Currie and Kenneth Lavrsen
5.	Security team creates advisory with hotfix	2009-04-26	Done	Kenneth Lavrsen
6.	Release Manager builds patch release	2009-04-25	Done	Kenneth Lavrsen
7.	Send alert to foswiki-announce and foswiki-discuss mailing lists	2009-04-27	Done	Kenneth Lavrsen
8.	Publish advisory in Support web and update all related topics	2009-04-29	Done	Kenneth Lavrsen
9.	Reference to public advisory on Download page and Known Issues	2009-04-29	Done	Kenneth Lavrsen
10.	Issue a public security advisory ([email protected], [email protected], [email protected], [email protected], [email protected])	2009-04-29	Done	Kenneth Lavrsen
11.	Develop a secure token / double submit CSRF countermeasure feature to be released in next regular patch release	2009-06-19	Done	Crawford Currie
12.	Release 1.0.6 which includes the enhanced CSRF countermeasure feature	2009-06-21	Done	Kenneth Lavrsen
13.	Add the information about the additional countermeasures in 1.0.6 to the security advisory	2009-06-22	Done	Kenneth Lavrsen
14.	Send a notification about the update to the CVE to the same recipients that received the original advisory	2009-06-22	Done	Kenneth Lavrsen

• Set ALLOWTOPICCHANGE = SecurityGroup, IsaacLin