cross is now running Foswiki 2.1.3 Beta 1. Please open a task for any issues.
IDEA! Get Alerted: to get immediate alerts of high priority security issues, please join the low-volume foswiki-announce list - details at MailingLists

txt plain text

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

This advisory alerts you of a potential Cross-Site Request Forgery security issue with your Foswiki installation via HTTP GET requests, thereby allowing an attack to occur by simply viewing a web page that takes advantage of the exploit. This web page can be served by any web site, including the one hosting the Foswiki installation.

HELP Note: This advisory has been updated with new countermeasures (22 Jun 2009).

Severity Level

Severity 3 issue: Foswiki content or browser is compromised

The severity level was assigned by the Foswiki SecurityTaskTeam as documented in SecurityAlertProcess

MITRE Name for this Vulnerability

The Common Vulnerabilities and Exposures project has assigned the name CVE-2009-1434 to this vulnerability.

Vulnerable Software Versions

Fixed in Foswiki 1.0.6

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.


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).


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.


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
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="" />

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="">
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.


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 (,,,, 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

Topic revision: r19 - 11 Feb 2012, PaulHarvey - This page was cached on 18 Jan 2017 - 17:36.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License