Using Your Authorization Framework Correctly?

Many projects employ authorization frameworks to control and enforce permissions. Custom-built or off-the-shelf, how sure are you that your projects are using the framework in the correct way? And have authorization checks at all the necessary locations in your code base?

One way, of course, is code review. Have knowledgeable people point out the mistakes by looking over the code. Complete code reviews may be prohibitively expensive, though. Being a cross-cutting concern, you need to look at a lot of code for authorization aspects.

Penetration tests: definitely necessary. Still, penetration testing isn’t likely to find a one-time error in the usage of the authorization framework. Achieving a high coverage is very expensive.

So, what about authorization-focussed static analysis? It would definitely improve code review efficiency. Commercial static analysis tools still primarily look for programming errors, though. As authorization checks are typically employed in a structured manner, they can be easily analyzed if the framework is known well by static analysis rule developers.

For Rails apps, our Rails authorization plugin declarative_authorization comes with  support of this kind. In the screenshot, controller authorization analysis is shown. Possible flaws are highlighted in yellow and red and the found problems are displayed in tool tips.

Authorization Usage Browser for declarative_authorization

In the demo app, the authorization usage browser reveals which actions aren’t (properly) protected by authorization checks. For example, SessionsController#create is marked red for having no authorization check. This, of course, is intentional as this action allows users to login.

The yellow coloring of ConferencesController#index shows that this action is just generally protected and authorization constraints are not enforced. Again, this is intentional because index lists conferences and conference-specific authorization is checked at database query time. If other actions were marked in this way, the developer could easily make out the mistakes and correct potentionally highly critical bugs.

Try it out in the declarative_authorization demo application! And leave a note on whether this is of use to you.

For now, the tool analyzes authorization on controller level.  As declarative_authorization also comes with authorization for the model level and database query rewriting, a next step will be looking at issues in those areas as well.

One comment.

  1. hey :D

    keep up the good work, i’ve really missing this kind of approach to authorization!