Generate a Symfony password hash from the command line

There is an easy way to generate a Symfony compliant password hash from the command line. Assuming you’re using the bcrypt algorithm (the preferred choice according to Symfony’s security best practices), the default cost (13) and you have PHP >= 5.5 installed, just run the following command:

 It will output something like:  $2y$13$7mBTrD0lgdgBxt1.YbdvOOeSOrPUYOBfeC1Ra2osPs9lpCHdplw1m

You can directly use this value in your app/config/security.yml  file:

Thanks to Sarah Khalil, a built-in Symfony command will be available in a next release (and that command will support all installed algorithms).

DunglasAngularCsrfBundle: protect your Symfony / AngularJS apps against CSRF attacks

I create and I see more and more web applications sharing the same powerful architecture:

 These components share the same philosophy (built on top of dependency injection and MVC-like patterns, designed to be intensively tested) and play very well together.

This stack allows to create awesome blazing-fast web applications. Better, the client part and the server part of the app are loosely coupled, can evolve separately and can even be maintained by different teams.

However, this kind of apps often suffer of security problems, and especially Cross-site Request Forgery (CSRF or XSRF) vulnerabilities.

Both Symfony and AngularJS provide their own CSRF protection mechanisms, but by default they are not interoperable and not enabled. Thanks to a recent refactoring of the Symfony’s security component, it’s now possible and clean to make both systems working together, and I’ve just released an open source bundle to do that: DunglasAngularCsrfBundle.

This bundle provides out of the box CSRF protection for AngularJS apps interacting with a Symfony-backed app.

Despite it’s name, it does not depend of AngularJS and can also be used with Chaplin.js / Backbone.js, jQuery or even raw JavaScript. To do so, install and configure the bundle, then just add to XHR requests a HTTP header called X-XSRF-TOKEN containing the value of the token set by a cookie on the first HTTP request. The bundle will automatically check the validity of the provided token. If it is not valid, an Access Denied error (HTTP 401) will be thrown.

The bundle is fully tested with phpspec and obtain a platinum medal on the brand new (awesome) SensioLabs Insight quality monitoring system.

Internals documentation and installation instructions are provided on the GitHub page of the bundle. Check it, test it, star it and tell me what you think of it!

Download DunglasAngularCsrfBundle on GitHub. 

Patch to use sfXssSafePlugin with symfony 1.2

HTML Purifier is a awesome PHP filter library designed to secure and add standard compliance to HTML. In websites including user generated content, this library allow to have mutlimedia pages including image, text formating and YouTube videos in a secure and SEO proof way thanks to rich text editors like Tiny MCE or FCK Editor and HTML purifier.

A plugin called sfXssSafePlugin is designed to integrate this library as an escapement strategy in symfony. If you have tried it with symfony 1.2 you can see this message:

HTML Purifier autoloader registrar is not compatible
with non-static object methods due to PHP Bug #44144;
Please do not use HTMLPurifier.autoload.php (or any
file that includes this file); instead, place the code:
spl_autoload_register(array(‘HTMLPurifier_Bootstrap’, ‘autoload’))
after your own autoloaders.

There are also some strict standards and constants compatibility problems. I’ve just wrote a patch to get this plugin working with symfony 1.2.

  1. Install sfXssSafePlugin like described in its README file
  2. Download my patch in the plugin’s folder
  3. Go into the plugin’s folder and run patch lib/helper/XssSafeHelper.php < XssSafeHelper.php.patch
  4. Edit your application configuration file (ie: apps/frontend/config/frontendConfiguration.class.php) and add the following code into the configure() method:

It’s done ! I’ve submitted this patch to the plugin’s author. I hope it will be upstream soon 🙂

MessengerFX’s security problem corrected

Some times ago I found a Cross Site Scripting vulnerability in MessengerFX, a popular web-based Windows Live Messenger client. Friday I received from the team saying that the problem is now corrected:

Hi Kevin,
First of all i want to thank you for your warn. We fixed that problem and
now its working correctly.

[…]
If you find any other problem please let me know. Thanks again.

It was serious : Every software’s feature is available through Javascript. Any contact of a MessengerFX user can crash his browser, and futhermore get its contact list, add, remove, ban and unban contacts, read and send messages to any other contact of the victim ! Basically, an attacker just need to be listed in the contacts list of an MessengerFX user and this attacker can take control over the account.

In fact, all Javascript code is now removed server-side, so it’s impossible to send some snippets to a friend and the code is still executed locally (in the browser of the sender). The team explain that a new version of their app will be released soon and will better handle things like this.

MessengerFX allows your contacts to take control over your WLM

I have paste some HTML code to a Edouard using MessengerFX, a popular web Windows Live Messenger client based on AJAX, and – surprise, the code has been interpreted. Oh?! A XSS vulnerability ? Yes, and such a big one!

Every software’s feature is available through Javascript. Any contact of a MessengerFX user can crash his browser, and furthermore get its contact list, add, remove, ban and unban contacts, read and send messages to any other contact of the victim ! Basically, an attacker just need to be listed in the contacts list of an MessengerFX user and this attacker can take control over the account.

And the worst is coming… Using Javascript, it seems easy to write a worm that will, i.e. recursively delete every contacts of the MessengerFX users – say using the vulnerability to get the contact list and delete them one by one. The worm can also try to shutdown the WLM network with a DDOS attack by a heavy load of messages at the same timeusing infected MessengerFX users WLM accounts.

MessengerFX is popular and growing, such a flaw can be very dangerous for a lot of people. I have send a mail to the development team and I hope they will correct their application soon… Because the fix is as simple as a htmlspecialchars() call. MessengerFX users, don’t use it anymore and try Meebo or the official Microsoft WLM web based client. Web developers, never trust the user-submitted data and always escape thos inputs!!

Edit october 6 2008 : the problem is now corrected.