Merge pull request #2144 from HackTricks-wiki/research_update_src_network-services-pentesting_pentesting-web_django_20260418_025412

Research Update Enhanced src/network-services-pentesting/pen...

Author: carlospolop

src/network-services-pentesting/pentesting-web/django.md

@@ -23,6 +23,32 @@ This HackerOne report provides a great, reproducible example of exploiting Djang
 
 ---
 
+## Host Header / Password Reset Poisoning
+Django uses the request host to build absolute URLs in several common patterns: password reset emails, canonical links, redirects, `request.build_absolute_uri()`, sitemap generation, and multitenant logic. The framework validates the host only when code goes through `request.get_host()`. Therefore, **applications that read `request.META['HTTP_HOST']` or trust `HTTP_X_FORWARDED_HOST` in custom middleware can reintroduce classic Host header poisoning bugs even when `ALLOWED_HOSTS` is configured**.
+
+### High-value targets
+* Password reset and email verification links generated from `request.build_absolute_uri()`
+* Cache keys or reverse-proxy cache variations that include the host
+* Tenancy / white-label logic that picks branding, callback URLs, or storage buckets from the host
+* CSRF logic in deployments with attacker-controlled subdomains or overly broad cookie domains
+
+### Practical checks
+```http
+POST /accounts/password/reset/ HTTP/1.1
+Host: attacker.tld
+X-Forwarded-Host: attacker.tld
+X-Forwarded-Proto: https
+```
+
+Watch for:
+* Reset links, absolute redirects, or preview URLs containing the injected host
+* `SuspiciousOperation` only for `Host`, while `X-Forwarded-Host` still reaches application code
+* Absolute URLs built from `request.META['HTTP_HOST']` instead of `request.get_host()`
+
+Django's own security docs explicitly note that fake Host values can be used for CSRF, cache poisoning, and poisoning links in emails, and that reading the host directly from `request.META` bypasses `ALLOWED_HOSTS` protection. Also remember the CSRF limitation: if an attacker controls a subdomain and can set cookies for the parent domain, they may be able to satisfy the CSRF cookie/token check for the main app.
+
+---
+
 ## 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.
 
@@ -72,13 +98,27 @@ Applications built on Django commonly integrate xhtml2pdf/ReportLab to export vi
 
 ---
 
-## Pickle-Backed Session Cookie RCE
-If the setting `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` is enabled (or a custom serializer that deserialises pickle), Django *decrypts and unpickles* the session cookie **before** calling any view code. Therefore, possessing a valid signing key (the project `SECRET_KEY` by default) is enough for immediate remote code execution.
+## Pickle-Backed Signed Session Cookie RCE
+If the application uses `SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies'` together with `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` (or a custom serializer that deserialises pickle), Django will **unsign and unpickle attacker-controlled session data before view code runs**. In this configuration, a leaked `SECRET_KEY` immediately becomes an RCE primitive.
 
 ### Exploit Requirements
+* The server uses the signed-cookie session backend (`django.contrib.sessions.backends.signed_cookies`).
 * The server uses `PickleSerializer`.
 * The attacker knows / can guess `settings.SECRET_KEY` (leaks via GitHub, `.env`, error pages, etc.).
 
+### Recon and tooling
+If the whole session is stored client-side, the `sessionid` cookie is usually a long signed blob rather than a short opaque session key from a server-side session store. That is the situation where `SECRET_KEY` guessing, reuse, or disclosure matters the most.
+
+[`badsecrets`](https://github.com/blacklanternsecurity/badsecrets) can test Django signed cookies against known or weak secrets:
+
+```bash
+pip install badsecrets
+badsecrets --url https://target.tld/
+badsecrets '<sessionid_cookie_value>'
+```
+
+This is especially useful during wide scans for appliances or products that shipped with a hardcoded / tutorial `SECRET_KEY`, or after recovering a settings file from an LFI, debug page, or public repository.
+
 ### Proof-of-Concept
 ```python
 #!/usr/bin/env python3
@@ -95,23 +135,29 @@ print(f"sessionid={mal}")
 ```
 Send the resulting cookie, and the payload runs with the permissions of the WSGI worker.
 
-**Mitigations**: Keep the default `JSONSerializer`, rotate `SECRET_KEY`, and configure `SESSION_COOKIE_HTTPONLY`.
+**Mitigations**: keep the default `JSONSerializer`, rotate `SECRET_KEY`/`SECRET_KEY_FALLBACKS`, and leave `SESSION_COOKIE_HTTPONLY` enabled. Django's own signing/session docs explicitly recommend JSON here because JSON serialization prevents pickle-based code execution even if the signing key is exposed.
 
 ---
 
 ## Recent (2023-2025) High-Impact Django CVEs Pentesters Should Check
-* **CVE-2025-48432** – *Log Injection via unescaped `request.path`* (fixed June 4 2025). Allows attackers to smuggle newlines/ANSI codes into log files and poison downstream log analysis. Patch level ≥ 4.2.22 / 5.1.10 / 5.2.2. 
-* **CVE-2024-42005** – *Critical SQL injection* in `QuerySet.values()/values_list()` on `JSONField` (CVSS 9.8). Craft JSON keys to break out of quoting and execute arbitrary SQL. Fixed in 4.2.15 / 5.0.8. 
+These are useful as **version-gated testing hints**, but the important lesson is broader: recent Django SQLi fixes keep landing in places where developers assume "ORM == safe" while still passing attacker-controlled field names, JSON keys, or alias names into `*args` / `**kwargs`.
+
+* **CVE-2025-48432** – *Log injection via unescaped `request.path`* (fixed June 4 2025). Allows attackers to smuggle newlines/ANSI escape sequences into application logs and poison downstream log ingestion or analyst terminals. Patch level ≥ 4.2.22 / 5.1.10 / 5.2.2.
+* **CVE-2025-57833** – *SQL injection in `FilteredRelation` column aliases* (fixed September 3 2025). Dangerous pattern: attacker-controlled dictionary expansion into `QuerySet.annotate()` / `QuerySet.alias()` keyword arguments.
+* **CVE-2024-42005** – *SQL injection in `QuerySet.values()` / `values_list()` on `JSONField`* (fixed August 6 2024). Dangerous pattern: attacker-controlled JSON keys reaching `values(*user_keys)` or `values_list(*user_keys)`.
+* **CVE-2024-53908** – *SQL injection in direct `HasKey(lhs, rhs)` usage on Oracle* (fixed December 4 2024). The common `field__has_key='x'` syntax is unaffected; the risky case is hand-built lookup objects with untrusted `lhs`.
 
-Always fingerprint the exact framework version via the `X-Frame-Options` error page or `/static/admin/css/base.css` hash and test the above where applicable.
+Always fingerprint the exact framework version via the `X-Frame-Options` error page, `/static/admin/css/base.css` hashes, package metadata leaks, or debug stack traces, then test the affected call sites where user input influences lookup names or alias names rather than raw values.
 
 ---
 
 ## References
-* Django security release – "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. 
+* Django security release – "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" – [https://www.djangoproject.com/weblog/2025/jun/04/security-releases/](https://www.djangoproject.com/weblog/2025/jun/04/security-releases/)
+* Django security release – "Django 5.2.6, 5.1.12, 4.2.24 address CVE-2025-57833" – [https://www.djangoproject.com/weblog/2025/sep/03/security-releases/](https://www.djangoproject.com/weblog/2025/sep/03/security-releases/)
 * 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)
 * Django docs – QuerySet.values(): [https://docs.djangoproject.com/en/6.0/ref/models/querysets/#values](https://docs.djangoproject.com/en/6.0/ref/models/querysets/#values)
+* Django docs – Security in Django / Sessions / Signing: [https://docs.djangoproject.com/en/6.0/topics/security/](https://docs.djangoproject.com/en/6.0/topics/security/), [https://docs.djangoproject.com/en/6.0/topics/http/sessions/](https://docs.djangoproject.com/en/6.0/topics/http/sessions/), [https://docs.djangoproject.com/en/6.0/topics/signing/](https://docs.djangoproject.com/en/6.0/topics/signing/)
 * 0xdf: HackNet (HTB) — HTML Attribute Injection → Django SSTI → QuerySet.values data dump → Pickle FileBasedCache RCE – [https://0xdf.gitlab.io/2026/01/17/htb-hacknet.html](https://0xdf.gitlab.io/2026/01/17/htb-hacknet.html)
+* Black Lantern Security – Introducing Badsecrets / project repo: [https://blog.blacklanternsecurity.com/p/introducing-badsecrets](https://blog.blacklanternsecurity.com/p/introducing-badsecrets), [https://github.com/blacklanternsecurity/badsecrets](https://github.com/blacklanternsecurity/badsecrets)
 
 {{#include ../../banners/hacktricks-training.md}}