Conseils de sécurité pour Django

Quelle chance, vous utilisez Django, le framework web des perfectionnistes pressés (alias Django) ! L’équipe Django a beaucoup réfléchi à ses pratiques de sécurité (vous trouverez des fonctionnalités de sécurité dans sa documentation, et sa politique de sécurité mérite également le détour). Nous avons résumé quelques-uns des meilleurs conseils pour sécuriser votre projet Django.

Téléchargez notre aide-mémoire sur la sécurité de Django.

Connaissez votre version et utilisez-en une sécurisée

Quelle version de Django utilisez-vous ? Trois versions majeures de Django sont actuellement utilisées (même si le support à long terme de la version 1.11 prendra fin en avril 2020). La version de Django que vous utilisez a plusieurs conséquences pour votre projet. Par exemple, Django 1.11 est la dernière version à prendre en charge Python 2, dont le support a pris fin début 2020.

De plus, le choix de la version détermine les vulnérabilités connues présentes dans votre application et susceptibles d’être exploitées. Pour en savoir plus sur les vulnérabilités connues de Django, consultez notre base de données des vulnérabilités ou analysez votre projet avec Snyk : nous vous indiquerons si vous utilisez une version vulnérable.

Enfin, il est important de prévoir comment maintenir votre version de Django à jour. En général, il est préférable d’opter pour une version bénéficiant d’un support à long terme et de prévoir de passer à la version suivante avant la fin du support de votre version actuelle. Vous bénéficiez ainsi de l’assistance des mainteneurs sans avoir à changer constamment de version.

À noter : veillez à consulter la documentation correspondant à la version de Django que vous utilisez. Vous ne voudriez pas croire qu’une politique de sécurité est en place parce que vous l’avez lue dans la documentation, puis découvrir que la version que vous utilisez ne correspond pas à celle de la documentation consultée.

Limitez les tentatives d’authentification des utilisateurs

Django intègre de nombreuses fonctionnalités de sécurité, mais son système d’authentification ne protège pas nativement contre les attaques par force brute. Un acteur malveillant pourrait multiplier les tentatives de connexion à votre système et potentiellement y accéder.

Si ce type d’attaque vous préoccupe, utilisez un projet comme Django Defender pour bloquer les utilisateurs après un trop grand nombre de tentatives de connexion.

Protégez votre code source

Protéger votre code source peut sembler évident, mais cette démarche comporte plusieurs aspects qui méritent d’être explorés. Vous pouvez notamment veiller à ce que votre code source ne se trouve pas dans le répertoire racine de votre serveur web. Sinon, il risque d’être servi ou d’être exécuté en partie d’une manière que vous n’aviez pas prévue.

Et cela va sans dire : si votre projet contient des informations sensibles, veillez à utiliser un dépôt privé sur GitHub, Bitbucket ou Gitlab. Veillez également à ne jamais enregistrer vos secrets dans votre système de gestion de versions, même si vous comptez utiliser un dépôt privé. Un dépôt privé ne le reste pas toujours, et on ne peut pas toujours faire confiance à toutes les personnes qui y ont accès.

Utilisez les requêtes brutes et le SQL personnalisé avec prudence

Même si écrire des requêtes SQL brutes et du SQL personnalisé peut être tentant, cela risque d’ouvrir la voie à une attaque. Le framework de mappage objet-relationnel (ORM) de Django est conçu pour simplifier l’interrogation de votre base de données. Les QuerySets sont construits à l’aide de la paramétrisation des requêtes. Les paramètres de requête sont dissociés du code SQL des requêtes. En utilisant toujours l’ORM, un utilisateur qui tenterait une injection SQL (exécuter du SQL arbitraire sur une base de données) aura beaucoup plus de mal à y parvenir.

Django permet d’utiliser des requêtes brutes, mais cette pratique n’est pas recommandée. Si vous les utilisez, veillez tout particulièrement à échapper correctement tous les paramètres. Si l’ORM de Django ne répond pas à vos besoins, vous pouvez utiliser un autre ORM avec Django. SQLAlchemy est un exemple d’ORM compatible avec Django. Si un autre ORM convient mieux à votre projet, mieux vaut l’utiliser plutôt que d’écrire de grandes quantités de SQL brut.

Utilisez HTTPS

Quel que soit le framework choisi, il est toujours préférable de déployer votre application derrière HTTPS. Vous empêcherez ainsi les utilisateurs malveillants d’intercepter les informations échangées entre le client et le serveur. Pour que HTTPS fonctionne correctement, vous devez vous assurer que vos paramètres sont bien configurés.

Les paramètres suivants sont importants pour utiliser HTTPS. Veillez à bien les comprendre et à les activer correctement. La documentation explique clairement ces paramètres, leurs valeurs sécurisées par défaut et les raisons pour lesquelles vous pourriez devoir les modifier dans certaines situations.

• SECURE_PROXY_SSL_HEADER

• SECURE_SSL_REDIRECT

• SESSION_COOKIE_SECURE

• CSRF_COOKIE_SECURE

• SECURE_HSTS_SECONDS

• SECURE_HSTS_INCLUDE_SUBDOMAINS

• SECURE_HSTS_PRELOAD

Surveillez vos en-têtes

Commençons par examiner l’en-tête de requête referer. Il contient l’adresse de la page web précédente depuis laquelle vous avez accédé à la page actuelle. Ces informations sont utiles, entre autres, à des fins d’analyse. Elles peuvent toutefois parfois poser problème, car les internautes n’aiment généralement pas être suivis sur le web. Pour des raisons de confidentialité, il est possible de désactiver cette fonctionnalité. L’en-tête referer-policy détermine si l’en-tête de requête referer est transmis. Dans certaines conditions, seules des informations partielles sont transmises ; dans d’autres, toutes les informations le sont, et parfois, aucun en-tête de requête referer n’est transmis.

Lorsque le site est servi via HTTPS, Django utilise l’en-tête de requête referer pour contribuer à prévenir les attaques de falsification de requête intersites (CSRF). Si votre en-tête referer-policy est trop strict, vous désactivez la protection CSRF de Django. Au final, vous devez mettre en balance les avantages en matière de confidentialité d’un en-tête referer-policy strict et ceux de la protection CSRF. Vous pouvez trouver un compromis en autorisant uniquement les référents de même origine dans votre en-tête referer-policy.

Manipulez vos cookies avec prudence

Certains cookies sont plus sécurisés que d’autres : par défaut, les cookies sont transmis via HTTP. Or, puisque nous avons établi que vous devez utiliser HTTPS, vous devez également vous assurer que vos cookies ne sont envoyés que via HTTPS. Pour éviter toute fuite de cookies, définissez les paramètres SESSION_COOKIE_SECURE et CSRF_COOKIE_SECURE sur True. Le navigateur n’enverra alors ces cookies que via des connexions HTTPS. La définition de ces paramètres sur true peut avoir des effets secondaires intéressants, mais vous pouvez les atténuer en redirigeant le trafic HTTP vers HTTPS.

Gérez soigneusement les fichiers envoyés par les utilisateurs

Si votre application web permet aux utilisateurs d’envoyer des fichiers, vous vous exposez à un vecteur d’attaque : la logique d’envoi doit donc être gérée avec soin. Tout d’abord, il est important de valider tous les fichiers envoyés afin de vérifier qu’ils correspondent bien à ce que vous attendez (par exemple, un fichier image et non un script PHP !). Vous ne voulez pas qu’un utilisateur puisse exécuter du code.

Plusieurs mesures permettent de valider les fichiers envoyés ou de les gérer avec davantage de précautions. En voici quelques-unes :

• Créez une liste blanche des types de fichiers autorisés

• Limitez la taille des fichiers envoyés afin d’éviter les problèmes de déni de service

• Désactivez les gestionnaires qui exécuteraient des fichiers statiques comme du code (par exemple, désactivez mod_php d’Apache)

• Tirez parti des protections contre les scripts intersites (XSS). Si vous servez le contenu des utilisateurs depuis un domaine de premier niveau distinct, ces protections s’activeront pour vous protéger. Il peut s’agir d’un domaine que vous gérez, mais il est probablement plus simple de servir les fichiers depuis un service cloud ou un fournisseur de réseau de diffusion de contenu.

Comprenez toutes vos dépendances

Si vous avez choisi une version de Django présentant peu ou pas de risques de sécurité connus, vous pensez peut-être qu’il ne reste aucun problème de sécurité à prendre en compte. Il est toutefois important de comprendre quelles bibliothèques open source Django importe et de savoir si elles présentent des vulnérabilités.

Lorsque vous incluez Django (ou n’importe quelle bibliothèque open source), vous incluez généralement _aussi_ toutes les bibliothèques utilisées par la bibliothèque choisie. L’open source repose sur l’open source, qui repose lui-même sur encore plus d’open source.

Les dépendances indirectes sont tout aussi susceptibles d’introduire des risques que les dépendances directes, mais ces risques sont moins souvent détectés. Un outil comme Snyk vous aide à comprendre l’ensemble de votre arborescence de dépendances. Et maintenant que Snyk propose des demandes de tirage contenant des correctifs pour Python, il n’a jamais été aussi facile de corriger les problèmes, même dans les dépendances indirectes.

Ne laissez pas la perfection être l’ennemie du bien

Chaque mesure de sécurité que vous prenez vous rapproche du bon chemin. Django s’adresse peut-être aux perfectionnistes pressés, mais votre code n’a pas besoin d’être parfait pour bénéficier d’une meilleure sécurité. En mettant en œuvre, dans la mesure du possible, les principes présentés ci-dessus, vous pouvez considérablement améliorer la sécurité de votre code et rendre votre projet plus sain et plus résilient. Bon codage, les Pythonistas !