Politique de sécurité de Django

L’équipe de développement de Django s’engage fortement au signalement et à la publication des failles de sécurité. De ce fait, un ensemble de règles a été adopté afin de se conformer à cet objectif. Celles-ci sont destinées à permettre de produire des mises à jour de sécurité de la distribution officielle de Django en temps voulu et d’en informer les distributeurs tiers.

Signalement des problèmes de sécurité

Version courte : veuillez signaler les problèmes de sécurité en écrivant à [e-mail].

La majorité des bogues normaux de Django sont signalés au travers de notre instance Trac publique, mais en raison de la nature sensible des problèmes de sécurité, nous demandons instamment de ne pas signaler ce genre de problèmes de manière publique.

Au lieu de cela, si vous pensez avoir découvert un problème dans Django qui pourrait avoir des implications en terme de sécurité, nous vous prions d’envoyer une description du problème par courriel à [e-mail]. Les messages envoyés à cette adresse sont destinés à l’équipe de sécurité.

Après avoir soumis le problème par courriel, vous devriez recevoir un accusé de réception de la part d’un membre de l’équipe de sécurité dans les 48 heures. En fonction de l’action à entreprendre, il est possible que vous receviez ensuite d’autres courriels de suivi.

Envoi de signalements chiffrés

Si vous souhaitez envoyer un message chiffré (facultatif), l’identifiant de clé publique de l’adresse [e-mail] est 0xfcb84b8d1d17f80b. Cette clé publique est disponible sur la plupart des serveurs de clés fréquemment utilisés.

How does Django evaluate a report

These are criteria used by the security team when evaluating whether a report requires a security release:

• The vulnerability is within a supported version of Django.

• The vulnerability applies to a production-grade Django application. This means the following do not require a security release:

  • Exploits that only affect local development, for example when using runserver.

  • Exploits which fail to follow security best practices, such as failure to sanitize user input. For other examples, see our security documentation.

  • Exploits in AI generated code that do not adhere to security best practices.

The security team may conclude that the source of the vulnerability is within the Python standard library, in which case the reporter will be asked to report the vulnerability to the Python core team. For further details see the Python security guidelines.

On occasion, a security release may be issued to help resolve a security vulnerability within a popular third-party package. These reports should come from the package maintainers.

If you are unsure whether your finding meets these criteria, please still report it privately by emailing [e-mail]. The security team will review your report and recommend the correct course of action.

Versions prises en charge

À tout moment, l’équipe Django fournit une prise en charge de sécurité officielle pour plusieurs versions de Django :

• La branche de développement main, hébergée sur GitHub, en passe de devenir la version majeure suivante de Django, est prise en charge au niveau sécurité. Les problèmes de sécurité qui ne touchent que cette branche main à l’exclusion de toute autre version stable publiée sont résolus de manière publique sans passer par le processus de divulgation.

• Les deux versions publiées de Django les plus récentes sont prises en charge au niveau sécurité. Par exemple, durant le cycle de développement amenant à la publication de Django 1.5, Django 1.4 et Django 1.3 sont pris en charge. Au moment de la publication de Django 1.5, la prise en charge de sécurité de Django 1.3 se termine.

• Les publications avec prise en charge à long terme sont prises en charge au niveau sécurité pour une période définie.

Lorsque de nouvelles versions sont publiées pour des raisons de sécurité, la note qui l’accompagne inclut une liste des versions concernées. Cette liste ne contient que les versions prises en charge de Django : les versions plus anciennes peuvent aussi être affectées, mais nous ne faisons pas de recherches pour le déterminer et nous n’offrons pas de correctifs ou de nouvelles publications pour ces versions.

Comment Django annonce les failles de sécurité

Notre processus d’annonce d’une faille de sécurité à partir d’une discussion privée jusqu’à son annonce publique se déroule en plusieurs étapes.

Environ une semaine avant l’annonce publique, nous envoyons deux notifications :

Tout d’abord, nous avertissons sur django-announce de la date et de l’heure approximatives de la publication de sécurité à venir, ainsi que de la gravité des problèmes. Ceci permet d’aider les organisations qui doivent s’assurer de disposer de personnel disponible pour s’occuper de l’analyse de l’annonce et de la mise à jour de Django, le cas échéant. Les niveaux de gravité sont :

• Elevé

  • Exécution de code à distance

  • Injection SQL

• Modéré

  • Vulnérabilité XSS (cross site scripting)

  • Vulnérabilité CSRF (cross site request forgery)

  • Attaques par déni de service

  • Échec d’authentification

• Faible

  • Exposition de données sensibles

  • Gestion des sessions endommagée

  • Redirections et transferts non validés

  • Problèmes dus à une option de configuration peu courante

Ensuite, nous avertissons une liste de personnes et organisations, principalement composée de fournisseurs de systèmes d’exploitation et d’autres distributeurs de Django. Ce courriel est signé avec la clé PGP d’une personne de l”équipe de publication de Django et consiste en :

• Une description complète du problème et les versions concernées de Django.

• Les étapes que nous suivrons pour remédier au problème.

• Les correctifs, le cas échéant, qui seront appliqués à Django.

• La date à laquelle l’équipe Django appliquera ces correctifs, produira les nouvelles versions et annoncera publiquement le problème.

Le jour de l’annonce publique, voici les mesures qui seront appliquées :

1. Les correctifs adéquats seront appliqués au code de Django.

2. La ou les publications adéquates seront produites en plaçant les nouveaux paquets sur le Répertoire des paquets Python et sur le site web djangoproject.com; ces publications sont étiquetées (tag) dans le dépôt git de Django.

3. Un article sera publié sur le blog officiel du développement de Django, décrivant le problème et sa résolution en détails, désignant les correctifs et nouvelles publications appropriés. La personne ayant signalé le problème sera citée si elle le souhaite.

4. Une notification sera envoyée aux listes de diffusion django-announce et [e-mail] en mentionnant le lien vers l’article de blog.

Si un problème signalé est jugé particulièrement urgent, par exemple en raison d’une exploitation publiquement connue, l’intervalle entre la notification précoce et l’annonce publique peut être considérablement raccourci.

De plus, si nous avons des raisons de penser que le problème signalé affecte d’autres cadriciels ou outils dans l’écosystème Python/web, il est possible que nous en discutions en privé avec les mainteneurs concernés et que l’annonce et la résolution soient coordonnées avec les leurs.

L’équipe Django maintient aussi une archive des problèmes de sécurité découverts dans Django.

Destinataires des notifications anticipées

La liste complète des personnes et organisations qui reçoivent les notifications anticipées des failles de sécurité n’est pas publique.

Nous essayons également de conserver cette liste aussi petite que possible, afin de pouvoir mieux contrôler le flux des informations confidentielles avant une divulgation. Ainsi, cette liste de notification n’est pas simplement une liste d’utilisateurs de Django et il ne suffit pas d’utiliser Django pour être éligible à figurer sur cette liste.

De manière générale, les destinataires des notifications de sécurité anticipées sont divisés en trois groupes :

1. Fournisseurs de systèmes d’exploitation et d’autres distributeurs de Django qui mettent à disposition une adresse suffisamment générique (pas d’adresse électronique personnelle) de contact pour le signalement de problèmes avec leur paquet Django ou pour des signalements de sécurité généraux. Dans tous les cas, ces adresses ne doivent pas être propagées vers des listes de diffusion publiques ou des systèmes de suivi de bogues. Les adresses qui redirigent vers l’adresse privée d’un mainteneur individuel ou d’un contact lié à la sécurité sont acceptables, même si nous préférons de loin des systèmes de suivi privés ou des groupes de contact de sécurité.

2. Au cas par cas, des mainteneurs de paquet individuels qui ont prouvé leur engagement à agir et répondre de manière responsable à ces notifications.

3. Au cas par cas, d’autres entités qui selon le jugement de l’équipe de développement de Django ont besoin d’être mis au courant des problèems de sécurité en cours. Typiquement, les membres de ce groupe sont parmi les utilisateurs ou distributeurs connus de Django qui gèrent de nombreux clients où pour lesquels l’impact de failles de sécurité est très important. On attendra d’eux qu’ils démontrent leur capacité à recevoir, à conserver confidentiel et à agir de manière responsable à ces notifications.

Entités d’audits de sécurité et d’analyses

Il n’est pas dans notre politique d’ajouter ces types d’entités à la liste de notifications.

Demande de notification

Si vous pensez que vous ou une organisation que vous êtes autorisé à représenter entre dans l’un des groupes décrits ci-dessus, vous pouvez demander à être ajouté à la liste de notification de Django en écrivant (en anglais) à [e-mail]. Comme sujet du message, veuillez utiliser « Security notification request ».

Votre demande doit inclure les informations suivantes :

• Votre nom réel complet ainsi que le nom de l’organisation que vous représentez, le cas échéant, de même que votre rôle dans celle-ci.

• Une explication détaillée présentant les raisons vous poussant à penser que vous ou votre organisation entrez dans un moins un des ensembles de critères énumérés plus haut.

• Une explication détaillée de la raison vous incitant à demander à recevoir les notifications de sécurité. Encore une fois, gardez en tête qu’il ne s’agit pas simplement d’une liste des utilisateurs de Django et que la très grande majorité des utilisateurs devraient s’inscrire à la liste django-announce pour recevoir des annonces par avance des dates de publication de sécurité, sans le détail des problèmes résolus, plutôt que de demander à recevoir les notifications détaillées.

• L’adresse électronique que vous proposez pour la réception des messages de notification.

• Une explication sur les personnes qui vont recevoir les messages envoyés à cette adresse, ainsi que des informations au sujet d’éventuelles actions automatiques qui seront entreprises (par ex. le remplissage d’un ticket confidentiel sur un système de suivi de bogues).

• Pour les personnes, l’identifiant d’une clé publique associée à l’adresse pouvant être utilisée pour vérifier les messages reçus de ces personnes et au besoin pour chiffrer les messages envoyés.

Une fois envoyée, votre demande sera prise en compte par l’équipe de développement de Django ; vous recevrez dans les 30 jours une réponse vous informant du statut de votre demande.

Veuillez également garder à l’esprit que pour tout individu ou organisation, la réception des notifications de sécurité est un privilège accordé à la seule discrétion de l’équipe de développement de Django et que ce privilège peut être retiré en tout temps, avec ou sans justification.

Fournissez toutes les informations requises

Tout manquement aux informations requises à fournir lors de votre contact initial jouera contre vous lors de la décision d’approuver ou non votre requête.