flawopen.com/Desserialização Java/Segurança do ObjectInputStream

ObjectInputStream do Java é seguro para dados não confiáveis?

Referência de segurança Java

Em linguagem simples

Em geral, não: readObject() reconstrói objetos Java e pode executar métodos de desserialização das classes. É como aceitar um formulário cujos anexos também executam suas próprias instruções. Um fluxo malicioso pode alcançar classes já disponíveis à aplicação. A execução depende das classes, bibliotecas, caminhos e limite de entrada; não acontece em toda chamada.

ARRISCADO: desserialização nativa

// Não passe bytes controlados por atacante aqui.
try (var in = new ObjectInputStream(untrustedStream)) {
    Object value = in.readObject();
    handle(value);
}

MAIS SEGURO: interpretar um tipo fixo

// Desative tipagem polimórfica ampla para entradas não confiáveis.
ObjectMapper mapper = new ObjectMapper();
OrderRequest value = mapper.readValue(
    untrustedBytes, OrderRequest.class
);
validate(value);

Como uma falha se torna alcançável

Uma API, fila, cache ou importador recebe bytes controlados pelo usuário. Se chegam a ObjectInputStream.readObject(), a JVM restaura objetos de classes serializáveis presentes no processo. Uma cadeia de gadgets é um caminho possível pelo comportamento dessas classes, não um payload embutido em todo fluxo. A Oracle documentou CVE-2015-4852 como caso específico: ataques sem autenticação via WebLogic T3 contra versões listadas. Isso não torna todo uso de ObjectInputStream remotamente acessível.

Se não puder remover a serialização nativa

✓Prefira JSON ou Protocol Buffers com esquema explícito; converta para DTO fixo e valide campos e autorização.
✓Se inevitável, configure ObjectInputFilter específico antes de readObject(); permita apenas as classes exatas necessárias e rejeite as demais.
✓Limite profundidade, referências, arrays e bytes conforme entradas válidas medidas. Uma allowlist não impede esgotamento de recursos.
✓Não habilite tipagem polimórfica ampla para JSON não confiável: metadados arbitrários de subtipo podem recriar objetos.
✓Atualize Java e dependências, remova bibliotecas sem uso e processe fluxos legados com privilégios mínimos e recursos limitados.

Pergunta frequente

Um ObjectInputFilter torna readObject() seguro?

Ele reduz o risco com allowlist estreita e limites antes da leitura, mas não é sanitizador universal. As classes permitidas, seu comportamento e a ativação real do filtro importam; validação e autorização continuam necessárias. Evite serialização nativa de dados controlados por usuários.

Fontes primárias

Veja também Desserialização insegura: riscos e correção Newtonsoft.Json TypeNameHandling: configuração segura? PHP unserialize() e entrada não confiável Segurança do pickle.load() em Python: riscos de dados não confiáveis Ruby YAML.load é seguro? Versões do Psych e safe_load .NET BinaryFormatter: riscos e migração