Security Audit 2009-09-02: Crypt Token Based Fix for CSRF Vulnerability
| Please join the
| To get immediate alerts of high priority security issues, please join the low-volume
twiki-announce list - details at TWikiAnnounceMailingList
This is an advisory for TWiki site administrators to secure their TWiki installation against CSRF (cross-site request forgery) exploits.
Affected Software Versions
- All TWiki releases prior to TWiki Release 4.3.2
Attack can be done by tricking an authenticated TWiki user into visiting a static HTML
Updates pages with the attackers content in TWiki as the viewing user, including members of the TWikiAdminGroup. This can be used to gain administrator privileges, change access permissions and do other things.
The TWiki SecurityTeam
triaged this issue as documented in TWikiSecurityAlertProcess
and assigned the following severity level:
- Severity 3 issue: TWiki content or browser is compromised.
MITRE Name for this Vulnerability
There is no CVE for this security audit, however there is a related CVE-2009-1339
assigned by The Common Vulnerabilities and Exposures project.
If you trick an authenticated TWiki user into visiting a static HTML
page on another side with below content, the browser will send the "csrf" web form as a POST request to TWiki, which in turn will process it.
<form action="http://example.com/twiki431/bin/save/Sandbox/TestTopic" method="post" name="csrf">
<input type="hidden" name="action_quietsave" value="1">
<input type="hidden" name="text" value="Secunia was here">
- Upgrade to the latest patched production TWiki-4.3.2, TWikiRelease04x03x02.
- Use the web server software to restrict access to the web pages served by TWiki.
Implications for TWiki Content Authors
adds additional protection against CSRF exploits. If enabled, TWiki protects content updates with a one-time-use crypt token that is passed along in HTML
forms. As a drawback, a user can no longer hit the browser back button to fix a typo; an "invalid crypt token" error message is shown if the user tries to save the page again.
There is a balance between security and user convenience. A TWiki administrator can enable and disable the crypt token based CSRF protection with the
configure setting. For mission critical public TWiki sites it is recommended to enable the crypt token; for firewalled TWiki sites it is usually OK to disable it.
Authors and Credits
- Wikipedia:Cross-site_request_forgery - CSRF overview on Wikipedia
- Cross Site Request Forgeries: Exploitation and Preventation
- Popular Websites vulnerable for CSRF attack
- Preventing CSRF Attacks
-- Contributors: PeterThoeny
I'd like to comment on the 'Implications' part.
Another thing is the usability drawback (user can not use browser's back button): I don't know how the token protection is implemented for TWiki. But the Back-Button problem occurs when a new unique token is generated for each request which makes submits originating from cached pages pretty useless. But although somewhat less secure it is generally safe enough to generate one token for the whole user session.
Points well taken on the need for CSRF protection behind firewall.
Also agree to keep token for the whole edit session. Please feel free to submit a feature proposal