Are you Token to me ?

Le but de cet article est d’aborder l’utilisation du mod_secdownload de Lighttpd. Ce module ne permet qu’un seul mode de protection basé sur l’expiration des URLs au bout d’une durée déterminée par l’administrateur. Une autre approche serait de créer des jetons qui expirent quand ils sont utilisés. Cette approche sera brièvement abordée à la fin de cet article.

Le principe de fonctionnement du module mod_secdownload est relativement simple, l’URL doit contenir : le chemin relatif du fichier à télécharger, la date de création de l’URL et une somme de contrôle servant à valider l’URL. Si la date de création est jugée trop loin dans le passé, un code d’erreur 410 est renvoyé. Si la somme de contrôle est invalide, un code d’erreur 403 est renvoyé. Si la date de création est suffisamment récente et que la somme de contrôle est correcte, le fichier est envoyé au client.

Gentlemen start our engines

Le module mod_secdownload est inclus dans la distribution de base de Lighttpd. Il faut néanmoins veiller à ce que le module soit chargé au lancement de Lighttpd. Ce qui donne dans lighttpd.conf :

server.modules              = (
...
                                "mod_secdownload",
...
)

La configuration du module se fait grâce à 4 paramètres :

  secdownload.secret = "MonSecret"
  secdownload.document-root = "/path/to/protected/files"
  secdownload.uri-prefix = "/telechargement/"

  secdownload.timeout = 30

• Le paramètre secret sert lors du calcul de la somme de contrôle. La sécurité de la protection est basée sur cette chaine de caractères, il est donc important de bien la choisir et de ne pas la divulguer.
• Le paramètre document-root sert à définir le chemin absolu du dossier contenant les données à proteger.
• Le paramètre uri-prefix est similaire aux directives Alias d’Apache. Chaque appel du type mondomaine.tld/uri-prefix sera traité par le module mod_secdownload
• Le paramètre timeout permet quand à lui de définir la durée en secondes pendant laquelle l’URL est valide

Et maintenant, je fais quoi ?

Une fois Lighttpd configuré, il faut que l’application Internet soit en mesure de générer des liens valides de téléchargements. Des implémentations simples sont disponibles sur le site de Lighttpd. Il est important de bien comprendre l’algorithme sous-jacent, une fois l’algorithme maîtrisé la création de liens de téléchargements est relativement aisée.

L’URL de téléchargement sera de la forme suivante :

<mondomaine.tld>/<uri-prefix>/<token>/<timestamp>/<chemin-relatif>

Le timestamp doit être au format Hexadecimal. Le token est la somme MD5 de la concaténation du secret définit dans la configuration Lighttpd, du chemin relatif du fichier (en y laissant le / du début du chemin) et du timestamp au format hexadecimal.

Le script générant les URLs de téléchargement a donc besoin de connaître le secret. Le token varie en fonction du temps et du fichier à télécharger. Il faut donc faire attention aux deux points suivant lors de l’implémentation du générateur d’URL de téléchargement :

• Le secret doit être stocké de manière sécurisée (fichier avec droits limités par exemple) afin de ne pas compromettre la protection
• Le générateur d’URLs doit avoir son horloge synchronisée avec le serveur de téléchargement

Et si je veux faire autrement ?

Une autre approche serait de créer un GUID (Global Unique ID) lors de la création de l’URL, stocker cet ID et de l’invalider une fois qu’il a été utilisé. Cette solution est plus complexe à mettre en place : il n’existe pas à ma connaissance de module Lighttpd permettant de mettre en place ce genre de scénario. Le téléchargement devra alors être géré par l’interpréteur PHP/Ruby/Python/… . De plus le stockage des IDs nécessite a priori l’utilisation d’une base de données.

Voici de manière synthétique les avantages et inconvénients des deux solutions :

• mod_secdownload : la vérification de la validité de l’URL est rapide et le téléchargement bénéficie des différentes optimisation de Lighttpd (IO asynchrones par exemple). Par contre, une URL est valide pour tout les client pendant le laps de temps défini dans la configuration. Cette solution est performante mais plus limitée. De plus la sécurité de l’ensemble de la solution est compromise dès lors que le secret est connu par un tiers.
• GUID par téléchargement : Cette solution est plus sécurisée, pour compromettre la solution, il faudrait obtenir un accès en écriture au système de stockage des IDs de téléchargements. Cependant, cette solution est plus lourde à mettre en place et moins performante car elle nécessite l’utilisation d’un interpréteur PHP/Ruby/Python/… lors du téléchargement du fichier.