Tags: view all tags

Security Audit 2009-09-02: Crypt Token Based Fix for CSRF Vulnerability

Please join the twiki-announce list:	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 Vectors

Attack can be done by tricking an authenticated TWiki user into visiting a static HTML page on another side, where a Javascript enabled browser will send an HTTP POST request to TWiki, which in turn will process the request as the TWiki user.

Impact

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.

Severity Level

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.

Details

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.

<html>
<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">
<input type="submit">
</form>
<body onLoad="Javascript:document.csrf.submit()">
</html>

Countermeasures

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

TWiki-4.3.2 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 {CryptToken}{Enable} 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

Credit to Stefan Cornelius of Secunia Research for disclosing the issue to the twiki-security mailing list
TWiki:Main/SopanShewale for creating the fix
TWiki:Main/SopanShewale and TWiki:Main/PeterThoeny for triaging the issue and for creating the security audit

External Resources

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, SopanShewale - 2009-09-02

Discussion

I'd like to comment on the 'Implications' part.

Why is it considered safe to disable the protection in a firewalled surrounding. There is a user logged in to TWiki with content author or even admin privileges. CSRF summarizes several different ways (the one mentioned in this article is only one) to trick the user into submitting a request. No firewall or encryption or disabling javascript will help here. The only valid countermeasure is the token-thing. So i consider it recommended in any case.

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.

-- PeterCarter - 2010-03-27

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.

-- PeterThoeny - 2010-03-28

BasicForm
TopicClassification	TWikiDeployment
TopicSummary
InterestedParties	SopanShewale
RelatedTopics	TWikiSecurityAlerts, SecurityAlert-CVE-2009-1339, CsrfFixUsingToken, TWikiSecurityMailingList, TWikiAnnounceMailingList

Topic revision: r11 - 2013-05-14 - PeterThoeny

Account
- Log In
- Register User

Edit
Attach

Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2026 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.