Como impedir ataques de deserialização em PHP

A deserialização em PHP é o processo de transformar uma sequência de dados em valores novamente utilizáveis pelo programa. Esse recurso é útil para guardar informações em cache, mover dados entre aplicações e salvar objetos em bancos de dados. O problema aparece quando o sistema aceita conteúdo controlado por terceiros e reconstrói objetos sem verificar sua origem ou seu tipo.

Em PHP, a função unserialize() pode acionar métodos internos durante a leitura dos dados. Se um invasor conseguir alterar o conteúdo serializado, ele pode explorar behaviors inesperados de classes disponíveis na aplicação. Dependendo do contexto, o resultado pode incluir leitura indevida de arquivos, execução de comandos, alteração de dados ou comprometimento da aplicação.

A boa notícia é que a maioria desses ataques pode ser evitada. Segurança aqui não depende de um único filtro. Você precisa combinar entrada confiável, formatos que não dependem da linguagem, validação de tipos, controle das classes disponíveis e manutenção da aplicação.

Este conteúdo tem caráter informativo. Decisões técnicas devem ser tomadas com profissional especializado.

O que é deserialização em PHP

Serialização é a conversão de um valor para uma representação que possa ser salva, enviada ou armazenada. A deserialização faz o caminho inverso e reconstrói o valor original.

Por exemplo, uma aplicação pode usar serialize() para transformar um array em uma string:

$dados = [
    'produto_id' => 42,
    'quantidade' => 3
];

$registro = serialize($dados);

Mais tarde, unserialize() recupera a estrutura:

$dados = unserialize($registro);

Quando todos os dados ficam sob controle da aplicação, o uso pode ser legítimo. O risco surge quando a string serializada é aceita diretamente de uma requisição HTTP, cookie, cabeçalho, fila de mensagens, arquivo enviado pelo usuário ou outra fonte que possa ser alterada.

O serialize de um objeto inclui informações sobre sua classe e propriedades. Ao reconstruir o objeto, o PHP pode executar métodos relacionados ao ciclo de vida do objeto, como __wakeup(), __unserialize(), __destruct() ou __toString(), conforme o código e a versão da linguagem. Esses métodos não precisam estar visíveis na chamada a unserialize() para participarem do processo.

A expressão "ataque de deserialização" costuma Designar uma cadeia de ações em que dados maliciosos exploram a lógica de classes existentes. Em muitos casos, o atacante não precisa injetar uma nova classe. Ele aproveita métodos e propriedades de componentes que já estão instalados, como bibliotecas de cache, manipulação de imagens ou comunicação.

Onde o risco aparece

Uma aplicação vulnerável costuma combinar alguns fatores:

• Receber uma string serializada de uma fonte não confiável.
• Passar essa string diretamente para unserialize() ou para uma função que a utilize internamente.
• Disponibilizar classes com métodos que realizam ações perigosas.
• Executar o código em um ambiente onde arquivos, rede ou comandos são acessíveis.

O risco não está na existência de unserialize(). Está no uso de dados serializados como se viessem de uma fonte confiável quando, na verdade, podem ter sido criados ou alterados por uma pessoa não autorizada.

Por que a deserialização é perigosa

O risco principal é a execução de código durante a reconstrução de um objeto. Em versões anteriores ao PHP 8.0, unserialize() permitia que os dados informassem classes existentes durante a desserialização. A partir dessa versão, allowed_classes passou a ser uma proteção importante e mais visível, mas o parâmetro não resolve todos os problemas.

Além da execução de código, a desserialização pode permitir outras ações, como:

• Alterar propriedades que controlam permissões ou estados da aplicação.
• Acessar arquivos disponíveis para o processo PHP.
• Realizar requisições de rede para sistemas internos.
• Consumir recursos e negatively afetar a disponibilidade do serviço.
• Provocar erros que revelam informações sobre o ambiente.

O impacto depende de quais classes estão carregadas, de quais métodos elas implementam e do que o processo da aplicação tem permissão para fazer. Em um servidor web, "o usuário do PHP" pode ter mais acesso do que parece. Ele pode ler arquivos da aplicação, acessar bancos de dados, abrir conexões ou executar programas disponíveis no sistema.

Dados falsificados

Dados falsificados não precisam conter umacharges para exploit em PHP. Em muitos casos, alteram propriedades legítimas de objetos. Dependendo da lógica do sistema, isso pode:

• Trocar identificadores de usuário ou conta administrativa.
• Alterar caminhos de arquivos.
• Modificar URLs de.callback.
• Mudar flags internas usadas em validações.
• Induzir a aplicação a aceitar um objeto que normalmente seria rejeitado.

É por isso que validar o formato do dado depois da desserialização pode ser tarde demais. Se a reconstrução já acionou métodos com efeitos colaterais, o dano pode ter ocorrido.

Cadeia de gadgets

Uma cadeia de gadgets é uma sequência em que métodos de classes aparentemente inofensivos são combinados para executar uma ação perigosa. Um único método pode chamar outro método, que acaba lendo um arquivo, executando um comando ou disparando uma requisição.

A expressão vem da analogia com peças de ferramentas. Uma peça, isoladamente, não faz muita coisa. Quando o sistema coloca várias peças em sequência, surge uma capacidade que não existia em nenhuma delas isoladamente.

O inventory de classes disponíveis influencia o ataque. Por isso, a mesma aplicação pode se comportar de forma diferente em dois ambientes. Uma biblioteca presente apenas em produção pode criar a última peça necessária para uma cadeia.

Como impedir ataques de deserialização em PHP

A defesa mais consistente começa antes da desserialização. Se o sistema puder trocar o formato, troque a serialização nativa do PHP por JSON ou por outro formato que contenha apenas dados, sem classes e métodos.

Prefira formatos sem código executável

Use JSON para comunicação entre componentes quando os dados forem formados por arrays, objetos simples, números, textos, booleanos e valores nulos. O JSON não carrega o nome de uma classe PHP e não instrui o interpretador a reconstruir métodos de um objeto específico.

$json = json_encode([
    'produto_id' => 42,
    'quantidade' => 3
], JSON_THROW_ON_ERROR);

$dados = json_decode($json, true, 512, JSON_THROW_ON_ERROR);

Essa troca não torna a aplicação segura por si só. Você ainda precisa validar tipos, campos obrigatórios e limites de tamanho. A vantagem é reduzir a superfície de ataque, retirando da equação a reconstrução de classes arbitrárias.

Evite também formatos como YAML, XML ou formatos próprios quando eles puderem carregar objetos, tags, callbacks ou referências perigosas. JSON costuma ser uma escolha previsível para dados estruturados, desde que a aplicação não dependa de atributos ou tipos específicos do PHP.

Nunca desserialize conteúdo externo diretamente

A regra mais simples é não executar unserialize() sobre uma string recebida diretamente de um usuário ou de um sistema externo.

Exemplo que deve ser evitado:

$conteudo = $_POST['dados'];
$objeto = unserialize($conteudo);

Com PHP 8.0 ou superior, a forma mínima de reduzir o risco é restringir as classes permitidas:

$objeto = unserialize($conteudo, [
    'allowed_classes' => false
]);

Com allowed_classes igual a false, o PHP não cria objetos a partir das classes informadas. Elementos escalares e arrays podem ser recuperados, conforme o conteúdo. Mesmo assim, a entrada continua sendo influênciável pela pessoa que a produziu.

Se você realmente precisa de objetos de uma ou poucas classes conhecidas, declare apenas essas classes:

$objeto = unserialize($conteudo, [
    'allowed_classes' => [App\ObjetoSeguro::class]
]);

A lista deve conter somente classes que:

• Tenham necessidade real de fluxo em formato serializado.
• Não implementem métodos de ciclo de vida perigosos sem necessidade.
• Não sejam usadas em operações destrutivas durante a construção do objeto.
• Passem por revisão de segurança.

Para dados simples, uma lista mais restritiva pode ser suficiente:

$objeto = unserialize($conteudo, [
    'allowed_classes' => false
]);

if (!is_array($objeto)) {
    throw new InvalidArgumentException('Estrutura de dados inválida.');
}

Valide o formato antes de reconstruir o valor

Valide a entrada com o filter_var() usando FILTER_VALIDATE_BOOL ou uma regra equivalente no fluxo da aplicação. A validação precisa ocorrer antes de unserialize():

$entrada = $_POST['dados'] ?? null;

if (!is_string($entrada)) {
    throw new InvalidArgumentException('Conteúdo inválido.');
}

if (strlen($entrada) > 65536) {
    throw new InvalidArgumentException('Conteúdo excede o limite permitido.');
}

if (!preg_match('/^a:[0-9]+:\{.*\}$/s', $entrada)) {
    throw new InvalidArgumentException('Formato não permitido.');
}

$objeto = unserialize($entrada, [
    'allowed_classes' => false
]);

A expressão regular é apenas um exemplo e deve ser ajustada ao formato realmente usado. Em sistemas complexos, expressões regulares grandes podem causar consumo excessivo de CPU. O ideal é combinar validação de tamanho, estrutural e testes específicos.

Não confie apenas na aparência da string. Um dado pode começar como um array e esconder outros tipos dentro dele. Também é importante rejeitar conteúdo quando o formato não corresponde ao contrato esperado.

Use hash para validar arquivos ou registros

Se o conteúdo serializado for armazenado localmente, você pode validar sua integridade antes de desserializá-lo. Um hash criptográfico, calculado com hash_hmac(), pode detectar alterações:

$segredo = 'guarde este segredo no cofre de configuração';
$hash = hash_hmac('sha256', $conteudo, $segredo);

if (!hash_equals($hash, $hashRecebido)) {
    throw new RuntimeException('Falha na validação de integridade.');
}

$objeto = unserialize($conteudo, [
    'allowed_classes' => false
]);

A chave não deve ficar no código-fonte nem em um arquivo acessível pela web. Quando o segredo é comprometido, o atacante pode recalcular o hash. O HMAC protege a integridade, mas não substitui o controle de permissões.

Reduza o superfície de classes disponíveis

Como a exploração pode depender de métodos de classes já carregadas, limite o que está disponível no processo que processa dados externos. Evite carregar bibliotecas desnecessárias antes de validar a entrada. Em sistemas complexos, isso pode exigir uma revisão da arquitetura, do Autoload e da inicialização da aplicação.

Algumas medidas complementares incluem:

• Atualizar PHP, extensões e bibliotecas.
• Remover pacotes abandonados ou sem uso.
• Isolar tarefas de processamento de conteúdo.
• Executar o worker com privilégios mínimos.
• Restringir acesso a arquivos, rede e comandos.
• Registrar tentativas anômalas de desserialização.

Restrinja permissões do processo

Uma aplicação web não deveria precisar de acesso a todo o sistema de arquivos ou a comandos do sistema operacional. Configure o usuário do PHP, do PHP-FPM ou do contêiner com permissões mínimas.

No caso de contêineres, prefira sistemas de arquivos somente leitura quando a arquitetura permitir, monte secrets de forma segura e restrinja a rede por padrão. Em hospedagens compartilhadas, as permissões adequadas dependem do provedor, mas a remoção de permissões de escrita desnecessárias continua sendo importante.

Essa camada não impede a desserialização. Ela limita o impacto caso alguma falha de validação permita que um dado malicioso seja reconstruído.

Monitore e responda a anomalias

Registre eventos relevantes sem colocar dados sensíveis ou conteúdo serializado completo nos logs. Informations úteis incluem origem da requisição, classe esperada, resultado da validação, identificador da requisição e horário.

Alertas podem ajudar a identificar:

• Tentativas repetidas de enviar payload serializado.
• Falhas frequentes de unserialize().
• Processos acessando arquivos incomuns.
• Novas classes carregadas após uma atualização.
• Picos de CPU durante operações de desserialização.

O log não deve ser o único controle. Ele ajuda a detectar e investigar, mas precisa vir acompanhado de uma proteção preventiva.

Mantenha PHP e dependências atualizados

Atualizações do PHP corrigem falhas de segurança e mudam o comportamento de funções sensíveis. A política de allowed_classes, por exemplo, passou a ser aplicada de forma diferente a partir do PHP 8.0.

Use uma rotina de atualização que inclua:

• PHP e extensões principais.
• Bibliotecas de aplicação.
• Servidor web.
• Sistema operacional.
• Containers e imagens de base.

Também registre a versão usada no ambiente e execute testes após cada atualização. Uma versão nova não substitui a validação de entrada, mas evita que o ambiente permaneça preso a comportamentos antigos ou vulnerabilidades corrigidas.

Comparativo entre estratégias de proteção

Nenhuma técnica isolada cobre todos os cenários. A escolha depende da necessidade de usar objetos, da origem dos dados e do modelo de ameaça.

A estratégia mais segura começa pela redução da necessidade de desserializar objetos. Quando o fluxo permite usar JSON e validação de contrato, você elimina uma categoria inteira de riscos.

Onde a validação deve acontecer

A validação precisa estar perto do ponto em que a confiança é estabelecida. Isso significa identificar quem produziu o dado, como ele chegou, se há assinatura, qual é o formato esperado e quais tipos podem existir.

Uma arquitetura comum possui camadas assim:

1. Receber a requisição ou mensagem.
2. Verificar origem, autenticação e assinatura.
3. Limitar tamanho do conteúdo.
4. Validar a estrutura externa.
5. Reconstruir o dado com restrições.
6. Validar o contrato de negócio.
7. Processar a ação autorizada.

A etapa seis não elimina efeitos colaterais da etapa cinco. Ela protege a lógica da aplicação, mas precisa vir depois da reconstrução segura.

Testes de segurança para o código PHP

Crie testes que confirmem que entradas desconhecidas não produzem objetos inesperados. Um teste básico pode verificar que uma classe proibida não seja reconstruída:

$payload = 'O:8:"Classe":0:{}';
$resultado = unserialize($payload, [
    'allowed_classes' => false
]);

$this->assertIsNotObject($resultado);

O teste deve usar uma classe fictícia ou um nome que não exista no ambiente. Também é útil testar tamanho excessivo, formato corrompido, campos ausentes, tipos inesperados e conteúdo com classes não permitidas.

Em aplicações web, inclua testes de integração para que endpoints não aceitem diretamente o parâmetro serializado. Se o formulário deveria enviar JSON, um payload PHP serializado precisa ser rejeitado.

Cuidados com integração, cookies e filas

Nem toda desserialização ocorre em um endpoint visível. Sistemas distribuídos também transportam dados entre aplicações, e um valor confiável dentro de uma rede pode ter sido alterado fora dela.

Cookies

Cookies são armazenados no navegador do usuário. A pessoa que visita o site pode editar o valor do cookie. Por isso, dados relevantes depender de um cookie sem assinatura e validação.

Como referência, setcookie() possui opções de segurança como Secure, HttpOnly e SameSite. Elas protegem aspects diferentes, mas não autenticam o conteúdo por si só. Um cookie assinado exige uma chave segura, comparação constante e rotação de chaves.

Webhooks

Webhook envia eventos de um serviço para sua aplicação. O serviço precisa se autenticar na entrada. Use a assinatura fornecida pela plataforma, calcule o HMAC sobre o corpo exato recebido e compare com hash_equals().

Evite processar o webhook antes de validar a assinatura. Se o corpo for desserializado antes dessa checagem, a proteção chega tarde demais.

Filas de mensagens

Mensagens em filas podem ser alteradas por consumidores, sistemas intermediários ou credenciais comprometidas. O consumidor deve validar o formato e a origem. Quando possível, prefira JSON e aplique um schema, como JSON Schema, compatível com o contrato da mensagem.

Cache

Dados serializados em cache continuam sujeitos à origem. Se o cache for compartilhado entre aplicações ou preenchido por workers com privilégios diferentes.thenavegação da? Uma ameaça. O cache deve ter namespaces, permissões e validação de integridade compatíveis com o risco.

O que fazer quando o código legado já usa unserialize

Migrar uma aplicação antiga pode ser demorado. Você pode criar etapas intermediárias para reduzir a exposição enquanto conduz a mudança.

Etapa 1, inventário dos usos

Localize todas as chamadas a unserialize(), inclusive dentro de bibliotecas. Verifique também funções que recebem formato serializado, como algumas rotinas de sessão ou armazenamento.

Para cada ocorrência, registre:

• Origem do conteúdo.
• Classes esperadas.
• Necessidade de preservar objetos.
• Risco de negócio envolvido.
• Possibilidade de substituição por JSON.

Etapa 2, contenção imediata

Nas chamadas existentes, adicione allowed_classes, limite o tamanho da entrada e valide o formato. Se a informação não precisar de classes, use false.

Também procure usages sem proteção em plugins, pacotes e componentes de terceiros. Atualizar bibliotecas pode corrigir problemas conhecidos, mas ainda é necessário avaliar a forma como a aplicação usa os dados.

Etapa 3, migração para JSON

Crie uma função central para ler e gravar o payload. Faça a leitura tolerante ao formato antigo durante uma transição controlada. Exemplo conceitual:

function decodificarPayload(string $conteudo): array
{
    $dados = json_decode($conteudo, true);

    if (is_array($dados)) {
        return $dados;
    }

    throw new InvalidArgumentException('Payload JSON inválido.');
}

Em produção, a transição precisa de planos para dados já gravados, filas antigas e sessões existentes. Não basta alterar o código de leitura e esquecer que o banco ainda contém valores no formato serializado.

Etapa 4, validação de contrato

Mesmo com JSON, defina os campos aceitos, tipos obrigatórios e valores válidos. Um schema como JSON Schema pode documentar e automatizar essa etapa.

Exemplo de contrato em JSON Schema:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["produto_id", "quantidade"],
  "properties": {
    "produto_id": {
      "type": "integer",
      "minimum": 1
    },
    "quantidade": {
      "type": "integer",
      "minimum": 1,
      "maximum": 999
    }
  }
}

O contrato deve refletir a regra de negócio. Limitar apenas a estrutura não garante que uma operação faça sentido.

Etapa 5, monitoramento e revisão

Observe erros, alertas, classes carregadas e tentativas de exploração. Faça revisões periódicas porque novas bibliotecas podem ampliar o inventory de gadgets ou introduzir novos usos de serialização.

Erros comuns na proteção contra deserialização

Confiar apenas em allowed_classes

allowed_classes é uma camada importante, mas não deve ser a única. A opção controla a reconstrução de objetos. Ela não elimina a necessidade de validar formato, tamanho e regras de negócio.

Permitir muitas classes por conveniência

Uma lista com dezenas de classes pode parecer segura porque rejeita classes aleatórias. No entanto, qualquer classe permitida pode introduzir um método perigoso. Uma lista pequena e revisada oferece uma superfície menor.

Validar somente depois do unserialize

Se a validação ocorre depois, o PHP já pode ter executado métodos durante a reconstrução. Validar antes reduz o risco e evita aceitar estruturas que não deveriam existir.

Confiar em endereço IP ou ambiente interno

Uma requisição originada de uma rede supposedly confiável ainda pode ter sido alterada por SSRF, comprometimento de credencial ou Supply Chain. A autenticação do conteúdo é mais forte do que confiar apenas na origem da conexão.

Assinar o dado e esquecer de proteger a chave

Uma assinatura sem segredo bem guardado não oferece proteção suficiente. Chaves em arquivos de configuração precisam de permissões restritas, rotação e gestão segura. Segredos nunca devem ser impressos em logs.

Esconder a vulnerabilidade no nome da função

Substituir unserialize() por uma função própria com o mesmo comportamento não cria segurança. O risco continua no processamento do formato e nas classes disponíveis.

Testar apenas o PHP 8 mais recente

Aplicações podem rodar em ambientes com versões diferentes, containers antigos ou servidores de hospedagem com configurações próprias. A matriz de versões deve fazer parte do processo de compatibilidade.

Checklist prático de hardening

Antes de considerar o fluxo pronto, revise os pontos principais:

• Todas as chamadas a unserialize() foram localizadas, inclusive em dependências.
• Os dados serializados vêm de uma origem cuja integridade está protegida?
• O tamanho máximo da entrada está definido?
• allowed_classes está definido nas chamadas necessárias?
• A lista de classes é pequena, revisada e realmente necessária?
• O formato pode ser substituído por JSON?
• A validação ocorre antes da reconstrução?
• JSON Schema ou outra validação de contrato está em uso?
• Webhooks e cookies possuem verificação de assinatura?
• As chaves estão fora do código-fonte e dos logs?
• O processo PHP possui permissões mínimas?
• A aplicação está atualizada?
• Existe monitoramento para falhas e formatos inesperados?

Um item importante é Differenciar "funciona" de "está protegido&quot. O teste que retorna o valor esperado não detecta todas as combinações de classes e métodos. Os testes de segurança precisam verificar também o que não deve ser reconstruído.

Perguntas Frequentes (FAQ)

O que é um ataque de deserialização em PHP?

É a exploração de dados serializados alterados para provocar comportamentos perigosos durante a reconstrução de objetos. O atacante pode explorar métodos como __wakeup(), __destruct() ou __unserialize(), dependendo das classes disponíveis, para realizar ações como acesso a arquivos, execução de comandos ou requisições de rede.

O parâmetro allowed_classes resolve o problema?

Ele reduz o risco ao restringir ou impedir a criação de objetos durante unserialize(), especialmente em PHP 8.0 ou superior. Ainda é necessário validar o formato, limitar o tamanho da entrada, proteger a origem dos dados e revisar as classes permitidas. A opção não torna uma entrada sem validação confiável.

É seguro usar unserialize com dados do banco de dados?\n

Depende. Se o banco fica sob controle exclusivo da aplicação e os registros não podem ser alterados por invasores ou usuários com permissão de escrita indevida, o risco é menor. Mesmo nesses casos, limite as classes, valide o conteúdo e considere JSON para novos registros. Dados vindos de outra aplicação ou de uma área editável exigem integridade verificável.

Como sei se meu site é vulnerável?

Procure usos de unserialize(), funções relacionadas e formatos serializados em plugins, temas e bibliotecas. Em seguida, identifique a origem dos dados, as classes permitidas e os métodos disponíveis. Uma análise de segurança deve testar entradas modificadas em ambiente controlado, sem expor o sistema de produção.

JSON elimina completamente o risco de injeção de objetos?\n

Não. JSON evita a mecânica de reconstrução de classes própria do PHP, mas a aplicação continua sujeita a entradas inválidas, valores fora dos limites, campos desconhecidos e permeability de negócio. Use JSON Schema, validação de tipos e tratamento de erros junto com a desserialização.

Conclusão

Impedir ataques de deserialização em PHP depende de quebrar a cadeia entre dados externos e execução de código. O passo mais importante é evitar unserialize() em conteúdo que possa ter sido alterado. Quando houver necessidade real, restrinja as classes, valide antes da reconstrução, aplique limites e proteja a origem do dado.

A segurança fica mais forte quando JSON substitui a serialização nativa, contratos de dados definem o que é aceito e o ambiente executa o PHP com privilégios mínimos. Atualizações, monitoramento e revisão de dependências completam a defesa.

Se você precisa de ajuda para colocar isso em prática, a Baita Site tem uma equipe especializada em sites, e-commerce, sistemas e inteligência artificial, com domínio total de WordPress. Fale com a gente e veja como podemos acelerar o seu projeto.

Referências consultadas

• Documentação oficial do PHP, función unserialize() e opções de segurança: www.php.net/manual/pt_BR/function.unserialize.php
• Documentação oficial do PHP, definição de allowed_classes e comportamento por versão: www.php.net/manual/pt_BR/function.unserialize.php#unseria…
• PHP Manual, referência sobre acesso seguro a dados serializados: www.php.net/manual/pt_BR/warnings.security.php
• OWASP, camada de serialização e recomendações sobre formatos de dados: owasp.org/www-community/vulnerabilities/Deserialization_o…
• OWASP Cheat Sheet, validação e controle de dados não confiáveis: cheatsheetseries.owasp.org/cheatsheets/Input_Validation_C…