CSRF mitigation: 4images Gallery's comprehensive approach

Once in awhile, in my quest to break (and promote fixing of) every web application I encounter, I have email discussions with some excellent people who reach out to me after the initial advisory during a coordinated disclosure.
Such was the case with Kai S. of Dots United GmbH, the team who develops the 4images Gallery.
Just a day or two after he'd been contacted by Secunia, whom I submit my vulnerability findings to for disclosure coordination, I heard directly from Kai. He asked me to provide more detail with regard to the finding indicating that 4images Gallery accepted "HTTP requests without performing any validity checks to verify the request", better known as cross-site request forgery (CSRF).
After replying with my proof of concept and some resource material, Kai replied that he would "forward this to our developers so we can release a fixed version".
On October 27 Dots United released a fix for all versions up to and including 1.7.8.
On November 10, the 4images Gallery team released version 1.7.9 inclusive of global CSRF mitigation.
In addition to a deserved "Well done!" for excellent communication as well as a timely fix turnaround, I'd like to applaud their direct approach to the fix, seemingly based on OWASP recommendations. Should all web application developers take a similar path, we'd likely see a reduction in CSRF vulnerability statistics.

Let me walk you through some of the 4images Gallery CSRF mitgation methods.
The core of the protection is includes/csrf_utils.php; CSRF protection is enabled by default.
As created by csrf_utils.php, generate a random MD5-derived token:



Return said token to the form as follows:



Then when some jerk like me comes along and throws something nasty at an admin...



...the attacker is thwarted by a unique, random token.



Add to the above-mentioned functionality the fact that the 4images devs allow you to take advanced control of CSRF protection via the config.php file. You can manage the default bit or maintain granular control of frontend/backend protection, token expiration, CSRF protection variable naming, and even XHTML vs. HTML.



I appreciate the efforts undertaken by Kai and the Dots United team in response to this vulnerability, and look forward to other development teams/vendors hopefully taking a similar tack.
Happy sailing. ;-)

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)