Content Disarm and Reconstruction (CDR)

Visão geral

O NextPDF Enterprise neutraliza um PDF não confiável por meio de Content Disarm and Reconstruction (CDR): ele analisa o arquivo, verifica-o em relação a limites de admissão, detecta recursos perigosos, remove-os e reconstrói um novo arquivo a partir dos objetos que permanecem. Os recursos perigosos são conteúdo ativo — scripts incorporados, ações de launch, arquivos incorporados, mídia rica e similares — que um visualizador pode executar ou sobre os quais pode agir. Esta página é de nível de comportamento: ela declara o que o mecanismo admite, o que ele remove, o que ele reconstrói e por que a saída não é uma cópia probatória.

O CDR é uma transformação destrutiva e unidirecional. A saída reconstruída é uma projeção de segurança da entrada, não uma cópia preservada ou equivalente em hash. Esse limite é declarado em Segurança e compliance.

Os pré-requisitos são declarados no front matter e repetidos em Pré-requisitos.

Disponibilidade e licenciamento

Este recurso é entregue no NextPDF Enterprise (nextpdf/enterprise) e é ativado com um envelope de licença de nível Enterprise. Uma implantação sem essa habilitação não carrega as classes do recurso. O NextPDF Core e o NextPDF Pro não fornecem CDR. O mecanismo é executado em processo; o documento não confiável é analisado e reconstruído no seu host. Compare edições e obtenha uma licença.

O que este recurso faz

O PDF suporta conteúdo ativo que um visualizador pode executar ou sobre o qual pode agir. Uma ação ECMAScript faz um processador de PDF executar um script que pode mudar valores de campo e aparências, conforme a ISO 32000-2 §12.6.4. Uma ação de launch inicia uma aplicação ou abre ou imprime um documento, conforme a ISO 32000-2 §12.6.4. Scripts de nível de documento no dicionário de nomes são executados automaticamente quando o documento é aberto, conforme a ISO 32000-2 §7.7.4. O CDR remove essas superfícies.

O mecanismo executa um pipeline ordenado:

1. Analisar o PDF de entrada.
2. Controle de admissão — verificar que o documento está dentro do limite de aceitação (contagem de objetos, contagem de páginas, tamanho do fluxo decodificado e uma razão de inflação de fluxo que defende contra entradas de bomba de descompressão). Um documento fora dos limites é rejeitado, não higienizado. A rejeição é relatada de forma distinta de um resultado de higienização, para que o seu tratamento de erros consiga diferenciar os dois.
3. Detectar ameaças — varrer em busca dos tipos de ameaça configurados.
4. Filtrar — particionar os objetos no conjunto seguro e no conjunto removido.
5. Limpeza de referências — limpar os ponteiros deixados pendentes pela remoção.
6. Reconstruir — serializar os objetos seguros em um novo PDF.

Os tipos de ameaça detectáveis incluem scripts incorporados (e a remoção agressiva de scripts que captura scripts em estruturas malformadas), gatilhos de ações adicionais e de open-action, ações de launch, ações de go-to remoto, ações de submit de formulário e de import-data, arquivos incorporados, mídia rica e conteúdo tridimensional, árvores de nomes de scripts de nível de documento, ações de Uniform Resource Identifier (URI) externas, dados de XML Forms Architecture, campos de formulário interativos, camadas de conteúdo opcional não padrão e objetos de assinatura digital (que uma reconstrução necessariamente invalida porque os byte ranges deixam de coincidir). Um objeto que não pode ser analisado é, ele próprio, tratado como um possível bypass e removido.

Três políticas definem os padrões:

• Standard — remove os tipos de ameaça de conteúdo ativo configurados e detectáveis pelo mecanismo; as atualizações incrementais são sempre achatadas para defender contra signature-shadowing, e esse achatamento não é configurável neste modo.
• Paranoid — as mesmas remoções com limites de recursos mais rígidos.
• Permissive — para fontes confiáveis: remove scripts e ações de launch, mas preserva as ações de URI, e torna o achatamento de atualizações incrementais configurável.

Por que funciona assim

O CDR reconstrói um novo arquivo a partir dos objetos que julgou seguros, em vez de excluir chaves perigosas no lugar. Essa postura de allow-list é a decisão que sustenta tudo. Um objeto que o detector nunca reconheceu — inclusive um que ele não conseguiu analisar — não sobrevive à saída, de modo que uma estrutura desconhecida falha de forma fechada em vez de escapar por uma brecha de deny-list. O controle de admissão é executado primeiro pela mesma razão: uma entrada fora do limite ou não analisável é rejeitada de imediato, nunca reconstruída parcialmente. O custo dessa segurança é a preservação. A reconstrução muda o layout de bytes, invalida assinaturas e descarta payloads cujo tipo de ameaça é removido — e é por isso que a saída é uma projeção de segurança, nunca uma cópia probatória.

Contexto de design: Sanitizing untrusted PDFs: content disarm and reconstruction.

Pré-requisitos

1. Instale o NextPDF Core e o pacote Enterprise, e mantenha uma licença Enterprise ativa.
2. Defina o limite de aceitação para suas entradas — a contagem máxima de objetos, a contagem de páginas, o tamanho do fluxo decodificado e a razão de inflação — ou use os limites de uma política predefinida.
3. Decida a política: standard para admissão geral de conteúdo não confiável, paranoid para a postura mais rígida ou permissive apenas para fontes confiáveis.

Configuração

A política é imutável e carrega:

• Tipos de ameaça a remover — o conjunto que o detector varre e que o reconstrutor remove.
• Tratamento de ações de URI — se as ações de URI externas são preservadas.
• Achatamento de atualizações incrementais — sempre ativo em standard e paranoid; configurável em permissive.
• Limites de admissão — contagem máxima de objetos, contagem de páginas, tamanho do fluxo decodificado e razão de inflação. Estes são o limite de aceitação, não o comportamento de higienização; excedê-los rejeita o documento.

Passo a passo

1. Leia os bytes do PDF não confiável.
2. Selecione uma política (standard, paranoid ou permissive) ou construa uma com limites explícitos.
3. Execute a operação de higienização do mecanismo com os bytes e a política.
4. Inspecione o resultado: se ele relatar não admitido, exponha o motivo da rejeição; caso contrário, use os bytes reconstruídos e a lista de ameaças removidas.
5. Trate a saída reconstruída como uma projeção higienizada, nunca como uma cópia probatória ou de arquivamento da entrada.

examples/enterprise/cdr-sanitize-guarded.php

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Enterprise\Security\Cdr\CdrEngine;
use NextPDF\Enterprise\Security\Cdr\CdrPolicy;
use NextPDF\Enterprise\Security\Cdr\CdrResult;
use Psr\Log\LoggerInterface;

final readonly class UntrustedPdfIntake
{
    public function __construct(
        private CdrEngine $engine,
        private LoggerInterface $logger,
    ) {}

    /**
     * Sanitize an untrusted PDF and distinguish rejection from a clean rebuild.
     *
     * An over-limit document is rejected by admission control, not sanitized;
     * the caller surfaces the rejection reason instead of trusting an empty
     * output. The rebuilt bytes are a security projection, never an
     * evidentiary copy of the input.
     *
     * @param string $pdfBytes The untrusted PDF bytes.
     *
     * @return CdrResult The sanitization result, including admission status.
     */
    public function sanitize(string $pdfBytes): CdrResult
    {
        $result = $this->engine->sanitize($pdfBytes, CdrPolicy::standard());

        if (! $result->admitted) {
            $this->logger->warning('PDF rejected by CDR admission control', [
                'reason' => $result->rejectionReason,
            ]);

            return $result;
        }

        $this->logger->info('PDF sanitized', [
            'removedThreats' => \count($result->removedThreats),
            'originalSize'   => $result->originalSize,
            'sanitizedSize'  => $result->sanitizedSize,
        ]);

        return $result;
    }
}

Verificação

1. Execute uma amostra que carregue uma superfície de conteúdo ativo conhecida (por exemplo, um script de nível de documento) e confirme que ela aparece na lista de ameaças removidas e está ausente da saída reconstruída.
2. Execute um documento fora do limite e confirme que o resultado relata não admitido com um motivo de rejeição, e que os bytes reconstruídos estão vazios.
3. Confirme que uma entrada assinada digitalmente tem seus objetos de assinatura removidos na reconstrução — uma reconstrução invalida a assinatura original porque os byte ranges mudam, então os objetos de assinatura obsoletos são removidos por design.
4. Abra a saída reconstruída em um visualizador e confirme que nenhum script é executado na abertura.

Segurança e compliance

• Não probatória. A saída reconstruída é uma projeção destrutiva e não reversível. Não a use para preservação de evidências legais, para comparação de hash com o original nem como cópia de arquivamento. Mantenha o original sob custódia separada se você precisar de uma cópia probatória.
• Admissão antes da higienização. Os limites de recursos são um limite de aceitação; um documento fora do limite é rejeitado, não higienizado. Relate a rejeição de forma distinta para que uma entrada fora do limite nunca seja confundida com uma reconstrução limpa.
• O conteúdo ativo é removido. Scripts, ações de launch, árvores de nomes de scripts de nível de documento, arquivos incorporados, mídia rica e superfícies similares são removidos — exatamente as ações que um visualizador, de outra forma, executaria (ISO 32000-2 §12.6.4 ação ECMAScript; ação de launch; scripts de nível de documento §7.7.4).
• As assinaturas são invalidadas pela reconstrução. Como a reconstrução muda o layout de bytes, a assinatura original não consegue mais validar; os objetos de assinatura são removidos em vez de deixados de forma enganosa no lugar.
• Com perdas por design. Os payloads de arquivos incorporados — incluindo anexos de fatura, como o Factur-X — são removidos quando seu tipo de ameaça é eliminado. O CDR é uma projeção de segurança, não uma camada de preservação.

Esta página trata de segurança de documentos. Toda fonte normativa é parafraseada; nenhum texto normativo é reproduzido.

Tratamento de falhas

• Falha de análise. Um documento que não pode ser analisado gera um resultado não admitido com um motivo de erro de análise, em vez de uma reconstrução parcial.
• Entrada fora do limite. O resultado relata não admitido com um motivo específico do limite; os bytes reconstruídos estão vazios.
• Objeto não analisável. Um objeto que não pode ser analisado é tratado como um possível bypass e removido, não mantido silenciosamente.
• Contagem de páginas com melhor esforço. A verificação de admissão por contagem de páginas é de melhor esforço; um catálogo malformado não derruba o pipeline, mas os limites de contagem de objetos e de fluxo ainda se aplicam.

Limite de publicação

Esta página documenta apenas o comportamento observável externamente e a superfície pública suportada da API. Caminhos de namespace internos, classes auxiliares, tabelas de mecanismo, nomes de arquivo de runbook e prefixos de ticket estão fora de escopo.

Consulte também

• Security — NextPDF Enterprise — a superfície de segurança Enterprise combinada.
• Validation — NextPDF Enterprise — verificação de conformidade de um PDF produzido ou reconstruído.
• Forensics — NextPDF Enterprise — exame e rastreamento de documentos.
• Security — NextPDF Core — a superfície de criptografia e assinatura do core.
• CDR · active content · shadow attack — termos do glossário.