When talking with @jmikola on #Symfony-dev this afternoon we got into the subject of cross site request forgery and symfony2 login forms. And it seems that form-login already supports this but neither of us knew how it worked. So here is another quick tip. This time about securing you login form from cross site attacks.

The key is to define a "csrf_provider" in your security.yml config file and point it to the "form.csrf_provider" provider. He also includes the controller and view code/templating you'll need to get the token included in the form (and validated).

In his latest postPaul Reinheimer looks at cross-site request forgeries and, despite the best efforts of the PHP security community, how developers still just miss the point in protecting their own code.

So, cross site request forgeries are a pretty common topic these days; they're in almost every security talk, book, site etc. This is okay; they're important [...] Most of the sites, and all of the books I've read demonstrate things correctly, but when it comes to actual implementation, time and time again, I see code that's just wrong.

He looks at two of the "essentials" when it comes to protecting you and your application - comparison (not taking other values of variables into account) and the unpredictable token (not making tokens, like md5 hashes of information, random enough).

Jani Hartikainen has posted a few ideas on cross site request forgeries in a new blog entry, including some methods to help prevent it in your application.

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. [...] This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example - and you wouldn't want that!

His method is a three-step process for protection - use POST, protect against cross-site scripting and use a CSRF key in the form to help prevent abuse. A simple script is included to show it working and is adapted to work in a controller plugin for the Zend Framework.

In this new post to his blog Stefan Esser looks at cross-site request forgeries and how they can be prevented in PHP 5.3 by two things - the request_order directive in your php.ini and by not using $_REQUEST anymore.

Although PHP 5.3 is still in alpha stage and certain features like the PHAR extension or the whole namespace support are still topics of endless discussions it already contains smaller changes that could improve the security of PHP applications a lot. [...] With request_order it is now possible to control in what order $_REQUEST is created and what variable sources are taken into account. This finally allows removing cookie data from $_REQUEST without removing them from $_COOKIE also.

He explains why the use of $_REQUEST can lead to such problems (and security holes) and notes that its use makes overriding an application's GET or POST values as simple as adding a cookie. There's even a method for creating a Denial of Service attack against a site using $_REQUEST like this. He points to an example similar to this that happened with phpMyAdmin a while back.

His recommendation?

Once PHP 5.3 is out it is recommended for hosters to set request_order to "GP" on all the servers running arbitrary PHP applications to protect applications [and] application developers on the other hand should finally move away from using $_REQUEST for user input.