M'enfin ?!?

Quand je travaille sur des modèles dans Rails, j'ai souvent besoin de regarder la liste des champs de ce modèle. Vous savez, ces petites questions toutes bêtes que l'on se pose tous : c'est firstname ou first_name ? phone ou mobile ? name ou title ? description ou body ?

Pour répondre à ces questions, il faut aller chercher dans db/schema.rb, fichier que l'on a rarement sous les yeux. Mais j'ai mieux à vous proposer : Annotate. C'est un gem qui ajoute un commentaire en haut de chacun de vos modèles (et tests unitaires) avec la déclaration du modèle en question.

Voici un exemple tiré de ma réécriture de LinuxFr.org en Rails :

# == Schema Information
# Schema version: 20090120005239
#
# Table name: news
#
#  id          :integer(4)      not null, primary key
#  state       :string(255)     default("draft"), not null
#  title       :string(255)
#  body        :text
#  second_part :text
#  section_id  :integer(4)
#  created_at  :datetime
#  updated_at  :datetime
#

Pour l'utiliser, c'est on ne peut plus simple. On fait un gem install annotate pour l'installer, puis on lance annotate quand on veut mettre à jour les commentaires. Pour ma part, je fais ça après chaque rake db:migrate, mais libre à chacun de le lancer quand il le souhaite.

Je commence une série d'articles sur des outils qu'il m'arrive d'utiliser quand je fais du développement Rails et qui mériterait, à mon avis, d'être plus connu. Le premier article de la série est Railroad.

Railroad est un script Ruby qui permet de générer des graphes à partir d'une application d'une Rails, ce qui peut être très pratique pour accompagner une documentation quand on a la flemme de faire ces diagrammes soi-même. Railroad permet de générer 3 types de graphes : un pour les modèles, un pour les controlleurs et un pour les machines à états d'acts_as_state_machine. Les diagrammes sont générés au format .dot, ce qui permet d'en faire facilement des .png ou des .svg avec la suite graphviz.

L'auteur du script original ne maintient plus ce script mais on peut en trouver des forks sur Github. Je conseille la branche de David Dollar : elle fonctionne avec les dernières versions de Rails et comporte mes patchs (1 2 et 3).

En pratique, on installe le gem ddollar-railroad, on ajoute une ligne à son fichier Rakefile et roulez jeunesse :

gem install ddollar-railroad
echo "require 'railroad/tasks/diagrams' if RAILS_ENV == 'development'" >> Rakefile
rake doc:diagrams

On obtient 3 diagrammes dans doc/diagrams (à condition que graphviz soit installé). Voici, par exemple, ceux que j'obtiens pour la version Rails de LinuxFr.org :

Introduction

La sécurité des applications web est souvent un sujet délicat : peu de temps à y consacrer, mais cela peut avoir des conséquences assez graves. Pas de panique ! Ruby on Rails est bien armé et avec un peu de rigueur, on peut se protéger sans trop de difficultés. Nous allons voir les principaux types d'attaques et comment les éviter.

Injections SQL

Commençons par un grand classique : les injections SQL. Une injection SQL consiste simplement à envoyer des données non prévues dans une requête SQL. Prenons comme exemple une application web où les utilisateurs sont authentifiés de la manière suivante :

@current_user = User.find(:first, :conditions => "login='#{params[:login]}' AND password='#{params[:password]}'")

En temps normal, quand Joe s'authentifie, la requête SQL suivante est exécutée :

SELECT * FROM users WHERE login='Joe' AND password='0521bc575b0ff61daa62494c7ae9c5b6' LIMIT 1;

Mais supposons maintenant que Kevin, un Script Kiddie, passe dans le coin et décide de mettre "Joe'; --" dans le champ login. La requête SQL va alors ressembler à :

SELECT * FROM users WHERE login='Joe'; --' AND password='00000000000000000000000000000000' LIMIT 1;

Kevin a réussi à se faire passer pour Joe sans connaître son mot de passe !

Heureusement, Active Record permet de nous en protéger assez facilement. Pour cela, il suffit d'utiliser les formes échappées comme cela :

@current_user = User.find(:first, :conditions => ["login=? AND password=?", params[:login], params[:password]])

ou de façon équivalente :

@current_user = User.find(:first, :conditions => {:login => params[:login], :password => params[:password]})

Dans les 2 cas, Active Record rajoutera un caractère '\' devant chaque apostrophe de façon à éviter les injections SQL.

L'authentification et la gestion des droits

Pour la grande majorité des projets, l'authentification (et la gestion des droits qui vont avec) est un passage obligé. Pour cela, il existe un certain nombre de points importants à respecter comme le chiffrement des mots de passe stockés en base de données (ce que nous n'avons pas fait dans l'exemple précédent). Les erreurs sont vite arrivées, aussi je vous recommande d'utiliser des plugins reconnus comme Restful Authentication, OpenID Authentication et Authorization.

Il ne vous reste plus qu'à faire attention à un dernier détail : mettre en cache des pages nécessitant une authentification est une mauvaise idée. En effet, ces pages vont alors être servies par le serveur web sans passer Rails, et donc sans vérification de l'authentification.

Se protéger des données forgées

L'étape suivante consiste à bien sécuriser l'accès aux données, aussi bien en lecture qu'en écriture. En effet, Rails possède quelques raccourcis très pratiques, mais qui peuvent poser problème quand ils sont mal maîtrisés. Le plus courant est l'affectation de masse, technique qui consiste à créer un objet Active Record directement depuis les paramètres de la requête HTTP. Par exemple, la création d'un compte utilisateur pourra s'effectuer de la façon suivante :

@user = User.create(params[:user])

Supposons maintenant que la table 'users' comporte un champ 'admin' qui vaut 0 par défaut ou 1 pour les super-utilisateurs. Un utilisateur malveillant pourrait forger la requête HTTP pour ajouter un paramètre useradmin=1 afin de gagner les pouvoirs réservés aux admins. La première solution pour se protéger de cette attaque consiste à écrire explicitement quels sont les paramètres autorisés :

@user = User.create(
        :login => params[:user][:login],
        :email => params[:user][:email],
        :password => params[:user][:password],
        :cgu => params[:user][:cgu])

Mais ceci peut vite devenir pénible quand on commence à avoir des formulaires un peu conséquents. C'est pourquoi on lui préfère généralement la deuxième solution : la déclaration dans le modèle de la liste des attributs qui ne peuvent pas être modifiés. Cette déclaration se fait à l'aide de la méthode attr_protected comme suit :

class User < ActiveRecord::Base
        attr_protected :admin
        ...
end

Nous pouvons de nouveau utiliser l'affectation de masse sans craindre qu'un utilisateur se fasse passer pour un admin, Rails s'occupe de filtrer les paramètres.

Dans le même style, un attaquant peut essayer de forger des URL. Si, par exemple, l'utilisateur authentifié peut supprimer l'item n°123 qui lui appartient, en appelant l'URL /items/delete/123, alors que se passera-t-il s'il appelle la même URL pour l'item n°456 qui ne lui appartient pas ? La réponse dépend du code de la méthode delete. Une implémentation de base pourrait ressembler à :

class ItemsController < ApplicationController
        def delete
                Item.delete(params[:id])
        end
end

Pour se protéger des URL forgées, on pourrait la transformer en :

class ItemsController < ApplicationController
        def delete
                @item = @current_user.items.find(params[:id])
                @item.delete if @item
        end
end

Ce n'est pas parfait (on pourrait vérifier que c'est bien une requête de type POST), mais c'est déjà beaucoup mieux.

Un dernier petit truc pour la route avant de passer à autre chose. Si vous avez une API pour laquelle vous utilisez la sérialisation XML, il peut être intéressant de surcharger ActiveRecord#to_xml pour que le champ secret_field n'y apparaisse pas :

class Item < ActiveRecord::Base
        def to_xml(args={})
                super({:except => [:secret_field]}.merge(args))
        end
end

Cross-Site Scripting

Jusque maintenant, nous avons vu des attaques directes : un utilisateur essaye de s'en prendre à notre site. Il existe également des attaques plus pernicieuses que l'on classe sous le nom de Cross-Site Scripting (XSS en abrégé). Leur but est de s'en prendre aux utilisateurs de notre site en glissant des cochonneries sur notre site. Ceci peut aller du spammeur qui mettra une balise <iframe> vers son site dans tous les formulaires qui lui passent sous la main à l'injection de javascript non maîtrisé.

Par exemple, quelqu'un crée un item dont la description est la suivante :

<script>document.location='http://www.programmez.com/';</script>

Si maintenant un visiteur affiche la description de cet item, il sera redirigé vers le site www.programmez.com. Vous vous dites que c'est ennuyeux mais pas bien méchant ? Oui, mais la même technique permet de voler les cookies et donc les sessions associées. Nous allons donc chercher à nous protéger de ces failles XSS.

Pour cela, il est important de faire une distinction entre 2 cas : est-ce que le champ que vous allez afficher peut contenir des balises HTML ou non ? Pour afficher le nom d'un item, on sera dans le premier cas, à savoir pas de balises HTML : on veut juste afficher le nom tel que l'a rentré son propriétaire. Par contre, on peut souhaiter être plus souple pour la description de l'item et laisser la possibilité d'avoir un titre (balise <h1>), du gras (<b>) ou de l'italique (<i>). Ces 2 cas ne se traitent pas de la même façon. Pour le premier cas, Rails nous offre un moyen simple de nous en protéger : le helper h. En pratique, à chaque fois que l'on souhaitera afficher le titre d'un item, on procédera de la manière suivante :

<%=h @item.title %>

Ce h va convertir les caractères qui pourraient être interprétés par un navigateur web en l'entité HTML correspondante. Problème résolu.

Le deuxième cas est par contre plus difficile à traiter. Vous pouvez être tenté d'utiliser un moteur de formatage de texte comme RedCloth. Attention, cela ne suffit pas à filtrer toutes les attaques ! Pour votre tranquillité, il vaut mieux utiliser le plugin WhiteList. Depuis Rails 2.0, ce plugin fait partie du framework et peut s'utiliser de la façon suivante :

<%= sanitize @item.description, :tags => %w(b i h1) %>

Il est possible de déclarer les balises autorisées de manière globale : je vous renvoie à la documentation officielle. Et pour ceux qui veulent être sûrs de ne pas oublier d'appel à h ou à sanitize, il existe des moteurs de template alternatifs comme Safe ERB ou Erubis. Ces moteurs adoptent l'approche opposée : ils filtrent par défaut tous les éléments <%= %>, charge au développeur d'indiquer explicitement ceux pour lequel le moteur ne fera pas de filtrage.

Cross-Site Request Forgeries

Juste avant de finir, je voudrais juste dire un mot sur un dernier type d'attaques. Les CSRF, abréviation de Cross-Site Request Forgery, sont des attaques complexes qui visent à forcer l'utilisateur à envoyer une requête HTTP vers notre site lorsque celui-ci visitera le site de l'attaquant. Je vous renvoie à wikipedia si vous voulez comprendre comment fonctionne ce type d'attaques. Sachez que Rails vous protège de celles-ci depuis la version 2.0 et qu'il existe un plugin pour les versions plus anciennes : CSRF-killer.

Conclusion

Nous avons pu voir qu'en prenant quelques bonnes habitudes, on pouvait développer des applications sûres en Rails. Il reste cependant des sujets que je n'ai pas abordés comme l'administration de Rails, apache ou MySQL (suite), la manipulation des fichiers ou encore le filtrage des informations sensibles dans les logs. Il est également important de se tenir au courant des mises à jour de sécurité de Rails et des plugins que vous utilisez.

Je remercie Benoît Sibaud pour sa relecture attentive.

Références

• http://www.rorsecurity.info/ruby-on...
• http://www.quarkruby.com/2007/9/20/...
• http://blog.innerewut.de/2008/1/3/2...
• http://www.owasp.org/index.php/OWAS...
• http://www.owasp.org/index.php/Top_...