Sécuriser la racine de votre projet Symfony
Chaque partie de Symfony prend en compte l'aspect sécurité. Que ce soit la gestion centralisée des utilisateurs, le nouveau système de routes permettant de personnaliser les méthodes d'accès (peer), ou les récentes corrections de sécurité de l'équipe Symfony...
Malgré cela, la manière dont les développeurs et les administrateurs de serveurs utilisent et mettent en place le framework peuvent causer des problèmes de sécurité majeurs.
J'ai récemment visité un projet Symfony où le répertoire web n'était pas configuré comme racine du VirtualHost d'Apache. En modifiant l'URL, j'ai rapidement réussi à afficher le nom d'utilisateur et le mot de passe de la base de données du projet, les plugins utilisés, les routes, le schéma de données, et toute information non stockée dans un fichier php (yml, sql, ...). En recherchant sur Google avec des mots clés spécifiques, j'ai rapidement été capable d'en trouver plusieurs centaines d'autres!
Nous sommes tous tentés de configurer un projet Symfony en dehors d'un VirtualHost, par exemple pour donner accès à une seconde version d'un site (c'était le cas dans l'exemple précédent) ou pour héberger plusieurs projets sous le même VirtualHost, mais ceci peut compromettre la sécurité des informations critiques que vous ne voulez pas mettre à disposition de pirates ou attaquants potentiels.
Si vous devez impérativement configurer un projet Symfony en dehors d'un VHost, alors sécuriser les répertoires système de Symfony et ne laissez accès qu'aux répertoires "web" en utilisant une règle comme celle présentée ici:
# Securing the project system folders
# Prevents access to any folder not named "web"
# Last modified on 2009.05.19 by Antoine Leclercq (antoine[dot]leclercq[at]letscod[dot]com)
SetEnvIf Request_URI "(/web/.*)$" allow
Order allow,deny
Allow from env=allow
Cela empêchera le serveur web de donner accès aux répertoires autre que ceux nommés "web".
C'est une des nombreuses méthodes pour corriger ce problème de sécurité mais je pense que ce genre de sécurisation supplémentaire devrait être intégrée dans les fichiers standards du Framework.
4 commentaires
Poster un commentaire