Riscos de desserialização no uso de BinaryFormatter e tipos relacionados
Este artigo aplica-se aos seguintes tipos:
Este artigo aplica-se às seguintes implementações .NET:
- .NET Framework todas as versões
- .NET Core 2.1 - 3.1
- .NET 5 e posterior
Atenção
O BinaryFormatter tipo é perigoso e não é recomendado para processamento de dados. Os aplicativos devem parar de usar BinaryFormatter
o mais rápido possível, mesmo que acreditem que os dados que estão processando são confiáveis. BinaryFormatter
é insegura e não pode ser tornada segura.
Nota
A partir do .NET 9, a implementação in-box BinaryFormatter lança exceções no uso, mesmo com as configurações que anteriormente habilitavam seu uso. Essas configurações também são removidas. Consulte o guia de migração BinaryFormatter para obter mais informações.
Vulnerabilidades de desserialização
As vulnerabilidades de desserialização são uma categoria de ameaça em que as cargas úteis de solicitação são processadas de forma insegura. Um invasor que aproveita com êxito essas vulnerabilidades contra um aplicativo pode causar negação de serviço (DoS), divulgação de informações ou execução remota de código dentro do aplicativo de destino. Esta categoria de risco faz consistentemente o Top 10 do OWASP. Os destinos incluem aplicativos escritos em uma variedade de linguagens, incluindo C/C++, Java e C#.
No .NET, o maior alvo de risco são os aplicativos que usam o BinaryFormatter tipo para desserializar dados. BinaryFormatter
é amplamente utilizado em todo o ecossistema .NET devido ao seu poder e à sua facilidade de uso. No entanto, esse mesmo poder dá aos atacantes a capacidade de influenciar o fluxo de controle dentro do aplicativo alvo. Ataques bem-sucedidos podem fazer com que o invasor seja capaz de executar código dentro do contexto do processo de destino.
Como uma analogia mais simples, suponha que chamar BinaryFormatter.Deserialize
uma carga útil é o equivalente a interpretar essa carga como um executável autônomo e lançá-la.
Vulnerabilidades de segurança BinaryFormatter
Aviso
O BinaryFormatter.Deserialize
método nunca é seguro quando usado com entradas não confiáveis. É altamente recomendável que os consumidores considerem usar uma das alternativas descritas mais adiante neste artigo.
BinaryFormatter
foi implementado antes de as vulnerabilidades de desserialização serem uma categoria de ameaça bem compreendida. Como resultado, o código não segue as melhores práticas modernas. O Deserialize
método pode ser usado como um vetor para os invasores executarem ataques DoS contra o consumo de aplicativos. Esses ataques podem fazer com que o aplicativo não responda ou resultar no encerramento inesperado do processo. Essa categoria de ataque não pode ser atenuada com uma SerializationBinder
ou qualquer outra BinaryFormatter
opção de configuração. O .NET considera esse comportamento por design e não emitirá uma atualização de código para modificar o comportamento.
BinaryFormatter.Deserialize
pode ser suscetível a outras categorias de ataque, como divulgação de informações ou execução remota de código. A utilização de recursos como um costume SerializationBinder pode ser insuficiente para mitigar adequadamente esses riscos. Existe a possibilidade de um invasor descobrir uma nova exploração que ignora as mitigações existentes. O .NET não se compromete a publicar patches em resposta a tais desvios. Além disso, desenvolver ou implantar esses patches pode ser tecnicamente inviável. Deve avaliar os seus cenários e considerar a sua potencial exposição a esses riscos.
Recomendamos que BinaryFormatter
os consumidores realizem avaliações de risco individuais em seus aplicativos. É da exclusiva responsabilidade do consumidor determinar se deve ou não utilizar BinaryFormatter
o . Se você está pensando em usá-lo, deve avaliar o risco das consequências de segurança, técnicas, de reputação, legais e regulatórias.
Alternativas preferidas
O .NET oferece vários serializadores in-box que podem lidar com dados não confiáveis com segurança:
- XmlSerializer e DataContractSerializer para serializar gráficos de objetos em e a partir de XML. Não confunda
DataContractSerializer
com NetDataContractSerializer. - BinaryReader e BinaryWriter para XML e JSON.
- As System.Text.Json APIs para serializar gráficos de objeto em JSON.
Alternativas perigosas
Evite os seguintes serializadores:
Todos os serializadores anteriores executam desserialização polimórfica irrestrita e são perigosos, assim como BinaryFormatter
.
Os riscos de assumir que os dados são fiáveis
Frequentemente, um desenvolvedor de aplicativos pode acreditar que está processando apenas entradas confiáveis. O caso de entrada segura é verdadeiro em algumas circunstâncias raras. Mas é muito mais comum que uma carga ultrapasse um limite de confiança sem que o desenvolvedor perceba.
Considere um servidor local onde os funcionários usam um cliente de desktop de suas estações de trabalho para interagir com o serviço. Este cenário pode ser visto ingenuamente como uma configuração "segura" onde a utilização BinaryFormatter
é aceitável. No entanto, esse cenário apresenta um vetor de malware que ganha acesso à máquina de um único funcionário para poder se espalhar por toda a empresa. Esse malware pode aproveitar o uso da BinaryFormatter
empresa para se mover lateralmente da estação de trabalho do funcionário para o servidor de back-end. Ele pode então exfiltrar os dados confidenciais da empresa. Esses dados podem incluir segredos comerciais ou dados de clientes.
Considere também um aplicativo que usa BinaryFormatter
para persistir o estado de salvamento. À primeira vista, isso pode parecer um cenário seguro, já que ler e gravar dados em seu próprio disco rígido representa uma ameaça menor. No entanto, o compartilhamento de documentos por e-mail ou pela internet é comum, e a maioria dos usuários finais não perceberia a abertura desses arquivos baixados como um comportamento de risco.
Este cenário pode ser aproveitado para efeitos nefastos. Se o aplicativo for um jogo, os usuários que compartilham arquivos salvos sem saber se colocam em risco. Os próprios desenvolvedores também podem ser visados. O invasor pode enviar um e-mail para o suporte técnico dos desenvolvedores, anexando um arquivo de dados mal-intencionado e pedindo à equipe de suporte para abri-lo. Este tipo de ataque pode dar ao atacante uma posição na empresa.
Outro cenário é onde o arquivo de dados é armazenado em armazenamento em nuvem e sincronizado automaticamente entre as máquinas do usuário. Um invasor que é capaz de obter acesso à conta de armazenamento em nuvem pode envenenar o arquivo de dados. Este ficheiro de dados será automaticamente sincronizado com as máquinas do utilizador. Da próxima vez que o usuário abrir o arquivo de dados, a carga útil do invasor será executada. Assim, o invasor pode aproveitar um comprometimento de conta de armazenamento em nuvem para obter permissões completas de execução de código.
Considere um aplicativo que passa de um modelo de instalação de área de trabalho para um modelo que prioriza a nuvem. Este cenário inclui aplicações que passam de uma aplicação de ambiente de trabalho ou modelo de cliente avançado para um modelo baseado na Web. Quaisquer modelos de ameaça desenhados para a aplicação de ambiente de trabalho não são necessariamente aplicáveis ao serviço baseado na nuvem. O modelo de ameaça para o aplicativo de desktop pode descartar uma determinada ameaça como "não interessante para o cliente atacar a si mesmo". Mas essa mesma ameaça pode se tornar interessante quando considera um usuário remoto (o cliente) atacando o próprio serviço de nuvem.
Nota
Em termos gerais, a intenção da serialização é transmitir um objeto para dentro ou para fora de um aplicativo. Um exercício de modelagem de ameaças quase sempre marca esse tipo de transferência de dados como cruzando um limite de confiança.
Consulte também
- Guia de migração BinaryFormatter
- Serialização binária
- YSoSerial.Net pesquisa sobre como os adversários atacam aplicativos que utilizam
BinaryFormatter
o . - Informações gerais sobre vulnerabilidades de desserialização: