Sécuriser un sous-domaine par cookies sous Lighttpd

Pour ceux qui ne le connaîtraient pas encore, Lighttpd (prononcez Lighty) est un serveur web Open Source léger et rapide initialement développé par l’Allemand Jan Kneschke dans l’idée de répondre à au problème : « Comment gérer 10000 connexions en parallèle sur un seul serveur« .

Il fait maintenant partie des 10 serveurs web les plus utilisés dans le monde.

Il plaît notamment grâce à sa faible consommation de mémoire (par rapport aux autres serveurs web) et sa gestion intelligente de la charge processeur.

Il est notamment beaucoup utilisé pour servir du contenu statique (images, fichiers CSS, javascript, …) bien qu’il gère également les langages serveur tel que PHP ou Perl via FastCGI.

Nous allons voir ici comment sécuriser un sous-domaine grâce aux cookies. Je ne vais cependant pas évoquer la partie qui concerne la configuration du sous-domaine dans Lighttpd.

Un petit cookie, ça vous dit ?

Avant de passer à la configuration de Lighttpd, il va falloir créer notre cookie. Pour cela vous pouvez utiliser divers outils tel que la Web Developer Toolbar de Firefox ou encore Firecookie (une autre extention Firefox).

Nous allons simplement utiliser la Web Developer Toolbar.

Si ce n’est pas déjà fait, installez l’extention à partir de cette adresse en cliquant sur le bouton Add to Firefox.

Une fois Firefox redémarré, une nouvelle barre d’outils devrait avoir fait son apparition en haut de votre navigateur (en dessous de votre barre personnelle) :

Comme vous vous en doutez, la partie qui nous intéresse ici est bien évidemment le menu « Cookies« .

Pour ceux qui se poseraient la question, vous n’êtes pas obligé de vous trouver sur une page de votre sous-domaine pour créer le cookie. Vous pouvez très bien le créer en surfant sur Google ou en lisant un article sur le développement web sur Tavuu.net ;-).

Rendez-vous dans Cookies puis Add cookie.
Les informations qui vous sont maintenant demandées sont pratiquement les mêmes qu’avec la fonction setcookie de PHP :

Name : entrez un nom secret pour votre cookie (c’est grâce à lui que Lighttpd saura si l’utilisateur a droit ou non d’accéder au sous-domaine).
Je vous conseille – pour plus de sécurité – de choisir une chaine aléatoire. Vous pouvez en générer une avec un générateur de mots de passe, par exemple.
Value : entrez ce que vous souhaitez, ça n’a pas d’importance ;-).
Host : ce champ est très important, c’est l’adresse sous laquelle le cookie sera disponible. Il faut donc y entrer l’adresse du sous-domaine à sécuriser.
Path : c’est le dossier du sous-domaine dans lequel le cookie sera disponible. Entrez / pour qu’il soit disponible dans tout le sous-domaine.
Expires : c’est la date d’expiration du cookie. J’ai ici juste modifié l’année pour 2030 (ça nous laisse un peu de marge ;-) ).
Session cookie : si coché, le cookie sera supprimé à la fin de la session (fermeture du navigateur).
Secure cookie : défini si le cookie ne doit être transmis que lors de connexions sécurisées (HTTPS). Si coché, le cookie ne sera pas disponible lors de l’accès au sous-domaine via HTTP.

Il ne vous reste plus qu’à cliquer sur le bouton OK.

Configuration de Lighttpd

Maintenant que notre cookie est créé, il ne nous reste plus qu’à configurer Lighttpd pour n’afficher le sous-domaine qu’aux utilisateurs autorisés (ceux qui possèdent notre fameux cookie ;-) ).

Rendez-vous dans le fichier où est configuré votre sous-domaine dans Lighttpd :

nano /etc/lighttpd/conf-enabled/sous-domaine.mon-domaine.com.conf

La variable qui contient les cookies dans Lighttpd s’appèle $HTTP["cookie"], il nous suffit donc d’une petite condition pour savoir si l’utilisateur est autorisé ou non à accéder au sous-domaine :

$HTTP["cookie"] =~ "moncookiesecret" {
	# L'utilisateur est autorisé
} else $HTTP["cookie"] !~ "moncookiesecret" {
	# L'utilisateur n'est pas autorisé
}

En complétant la condition présentée ci-dessus, vous pouvez par exemple rediriger l’utilisateur sur Google ou votre site principal si il n’est pas autorisé :

$HTTP["host"] =~ "sous-domaine.mon-domaine.com" {
	$HTTP["cookie"] =~ "moncookiesecret" {
		# L'utilisateur est autorisé : on lui affiche le sous-domaine
		server.name = "sous-domaine.mon-domaine.com"
		server.document-root = "/chemin/vers/les/fichiers/du/sous/domaine/"
	} else $HTTP["cookie"] !~ "moncookiesecret" {
		# L'utilisateur est n'est pas autorisé : on le redirige sur Google
		url.redirect = ( "^(.*)" => "http://www.google.com" )
	}
}

Vous pouvez également – si vous souhaitez brouiller les pistes des hackers – utiliser le mod_rewrite pour afficher une page qui n’existe pas et donc retourner une erreur 404 au lieu de rediriger sur Google :

url.rewrite-once = ( "^(.*)" => "/une/page/innexistante.html" )

Et Apache alors ?

Remarque : Je n’ai pas pu testé cette solution pour Apache. Si quelqu’un le fait et rencontre des problèmes n’hésitez pas à me le signaler. Merci ;-)

C’est bien sûr également possible sur Apache, il vous suffit d’ajouter les lignes suivantes dans le fichier .htaccess de votre sous-domaine pour que les utilisateurs non autorisés soient redirigés sur Google :

RewriteCond  %{HTTP_COOKIE}  !^.*moncookiesecret.*
RewriteRule  ^.*                 http://www.google.com  [L]

Si vous souhaitez plutôt – comme évoqué plus haut – afficher une erreur 404 aux utilisateurs non autorisés, ajoutez les lignes suivantes à votre fichier .htaccess

RewriteCond  %{HTTP_COOKIE}  !^.*moncookiesecret.*
RewriteRule  ^.*                 /une/page/innexistante.html  [L]

La fin ?

Il ne vous reste maintenant plus qu’à essayer d’accéder à votre sous-domaine avec et sans cookie pour être sûr qu’il sois bien sécurisé.

Pour tester le sous-domaine sans cookie, plutôt que de le supprimer, vous pouvez le désactiver : allez dans Cookies puis Disable Cookies et enfin All Cookies. Pour les réactiver c’est simple, refaites la même manipulation ;-).

J’espère que cet article vous aura été utile. Si vous avez des commentaires ou suggestions n’hésitez pas à m’en faire part via les commentaires ou directement à l’adresse leeroy.brun.