O patch do Django também exige olhar para cache, permissões e GDAL

O projeto Django publicou as versões 6.1.3, 6.0.10 e 5.2.19 com correções de segurança para seis problemas.[4] O anúncio cobre processamento de uploads, cache, permissões administrativas e operações geoespaciais, com falhas majoritariamente classificadas como de baixa severidade pela política do projeto.[4]

A leitura de engenharia não deveria parar na classificação. O trabalho é identificar quais caminhos da aplicação alcançam cada condição vulnerável e quais dependências participam da correção.

O que muda para quem desenvolve

Um dos problemas permitia que uploads multipart em base64 fossem armazenados integralmente em memória antes dos handlers, independentemente de FILE_UPLOAD_MAX_MEMORY_SIZE.[4] Outro fazia cabeçalhos ausentes e vazios produzirem a mesma chave de cache mesmo quando presentes em Vary, com potencial exposição de respostas privadas.[4]

Esses casos sugerem duas perguntas para a revisão: o limite de recurso é aplicado no ponto esperado? A chave de cache representa todas as diferenças relevantes da requisição? Recomendo transformá-las em critérios explícitos, em vez de confiar apenas na presença de uma configuração.

Na parte geoespacial, strings interpretadas pelo GDAL podiam provocar requisições de rede e leitura local, e a proteção completa para o problema de SpatialReference requer GDAL 3.9 ou posterior.[4] Portanto, considero insuficiente encerrar a mudança olhando somente a versão do pacote Django.

Como aplicar

Faça um mapa curto das funcionalidades utilizadas: uploads multipart, cache de páginas, modelos de usuário personalizados e entradas GeoJSON ou de referência espacial. Relacione cada uma à série instalada e à correção pertinente.

Em homologação, proponha pares de requisições com o cabeçalho relevante ausente e vazio. Confira o isolamento das respostas e a recomposição das entradas de cache. Para uploads, acompanhe memória durante uma carga sintética controlada, sem submeter produção a um ensaio de exaustão.

Se houver GeoDjango, registre a versão efetivamente carregada do GDAL no ambiente de execução. Prefira entradas geoespaciais de formato restrito e inclua na revisão os caminhos que aceitam strings fornecidas por usuários. No administrativo, confira o resultado com uma conta que tenha somente permissão de visualização.

Cuidados e limites

O anúncio recomenda SRIDs inteiros para dados não confiáveis ou listas explícitas de strings em versões antigas do GDAL, e apresenta o aviso gis.W001 para instalações abaixo da versão necessária.[4] A lista de commits da falha de exposição de hashes não inclui a branch 5.2, portanto não se deve presumir aplicabilidade idêntica dos seis problemas em todas as séries.[4]

Minha recomendação é atualizar a versão correspondente e guardar evidências por funcionalidade. Um pacote atualizado é parte da entrega. A outra parte é demonstrar que as condições relevantes da aplicação foram consideradas, inclusive a biblioteca nativa abaixo do código Python.

Fonte

[4] Fonte: Django Weblog