sfAntiBruteForcePlugin project

3 gravatar By Grégoire Marchal - 12/11/2010

Lately, I've created a small web application to play with the twitter API. My application is secured by a classic login/password: basic. I quickly wanted to add security on it, especially against brute force attacks. This kind of attack consists in trying a lot of login/password combinations on a form to find out a valid one (more info). I searched more information about this topic and hoped I found a symfony plugin. Result: no plugin, but a lot of interesting informations that encouraged me to start developing the wanted plugin! So I will summarize those informations here, make some kind of collaborative specifications for my plugin, and I hope you'll help me!

The most of informations I've collected come from this french (sorry...) tutorial: un anti brute-force léger et rapide.

The principle : prevent an user, and even more a bot, from trying a huge number of login/password combination on a given authentication page. Therefore, we have to count the failed attempts of users, and forbid them to try again when a given threshold is reached. Here are the things to specify.

What to use to identify attempts?

The client IP? Bad idea, this data is not reliable. Most of hackers will know how to modify it and will be able to make an infinity of attempts.

The PHP sessions? No, just erase the cookies and you're done...

On the login used for authentication? Well, it's not an ideal solution, but it's the best I've found for now. The main inconvenience is that anyone who knows your login can block your account...

If you have other ideas, let me know!

How to store the attempts counts?

In a database? It seems to be the more natural solution. But some projects don't use a database (and it's my case here!). I think it would be too intrusive to require a database and an ORM just for that.

In files? It's the way the above tutorial has chosen. About speed and load, I don't which way is the best. But this solution is less intrusive since it will work with any symfony project (I think).

If you have other ideas...

Where to proceed in symfony code?

At first, I thought I would have to create a filter to control accesses upstream. But the problem is, if I use the login to identify attempts, I need it to increase its counter. I also need to know if this attempts is a success or not. So I need to be in the controller to do that, in the action that manage the authentication process. So the developer will add that kind of call when an attempt fails:


This method will increment the counter for this user.

But before the authentication attempt, we have to check that the user can try (that he hasn't reached his threshold):

if (sfAntiBruteForceManager::canTryAuthentication($identifier))
  // ...

sfGuard integration ?

Later, probably. Don't put the cart before the horse! Let's keep it in mind.

So, here are the first leads for writing this plugin which will be, in my opinion, very useful for the developers who care about security (aka good developers!). I look forward to your remarks, suggestions, ideas!

PS : follow the evolutions on the official page of sfAntiBruteForcePlugin.

Watch your whereIn!

0 gravatar By Grégoire Marchal - 10/17/2010

Doctrine is cool, it makes live easier, we don't deal with big SQL queries any more, great. But sometimes it's vicious. Last example with the whereIn() method. On the face of it, there shouldn't be any problem, it just converts this:

$query->whereIn('id', array(1, 2, 3))

Into this:

AND id IN (1, 2, 3)

Let's imagine that the array parameter is dynamically built, and that sometimes it's empty... What's happen then? With MySQL, the "IN ()" instruction returns an error. What does Doctrine do? Well... Nothing. It ignores this criteria and executes the query, returning unexpected results... An exception is supposed to be thrown, but a bug prevents it. A ticket is opened... Be careful!

sfProjectAnalyserPlugin: is your code beautiful?

2 gravatar By Grégoire Marchal - 09/16/2010

If you believe you are a Symfony boss, if you think that your code respects the strictest standards, if you're sure that all your methods are documented, if you never calls sfContext::getInstance(), then you can face the terrific sfProjectAnalyserPlugin!

This plugin allows to measure the quality and the volumetry of a project. It counts the applications, modules and actions, checks the size of the functions and templates, alerts when it finds out abnormal stuff, and many other things.

It's not only a toy to generate some statistics about your work. It becomes definitely useful when it is used as a continuous integration tool. Imagine that you start a brand new Symfony project: if every morning, after your fried bacon, you launch the analysis and you follow the precious advices of the result page, you'll have in the end a beautiful, clean and easy to debug code. Then you'll become the king of oil and you could make a huge donation to the kind developers of this plugin!

And if you think it isn't strict enough (or too strict, shame on you :)), it's OK! It's completely configurable through a YAML file.

The analyse can be launched using a Symfony command :

symfony project:analyse --application="frontend" --env="dev" > analysis.html

It generates a HTML report that you can see using your favourite browser:

sfProjectAnalyserPlugin on sf sandbox

You can find more informations on the sfProjectAnalyserPlugin plugin page.

PS: you might have guessed that I'm one of the developers of this wonderful plugin! Even if my contribution has been modest for now... (I'll catch up, Loïc!)