Enterprise edizione

Disarmo e ricostruzione dei contenuti (CDR)

In sintesi

NextPDF Enterprise neutralizza un PDF non attendibile mediante il Content Disarm and Reconstruction (CDR): effettua il parsing del file, lo verifica rispetto ai limiti di ammissione, rileva le funzionalità pericolose, le rimuove e ricostruisce un nuovo file a partire dagli oggetti rimanenti. Le funzionalità pericolose sono contenuto attivo — script incorporati, azioni di avvio, file incorporati, rich media e simili — che un visualizzatore potrebbe eseguire o su cui potrebbe agire. Questa pagina è a livello di comportamento: indica ciò che il motore ammette, ciò che rimuove, ciò che ricostruisce e perché l’output non è una copia probatoria.

Il CDR è una trasformazione distruttiva e a senso unico. L’output ricostruito è una proiezione di sicurezza dell’input, non una copia preservata o hash-equivalente. Tale confine è indicato in Sicurezza e conformità.

I prerequisiti sono indicati nel front matter e ripetuti in Prerequisiti.

Disponibilità e licenze

Questa capacità è inclusa in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di livello Enterprise. Un deployment privo di tale entitlement non carica le classi della capacità. NextPDF Core e NextPDF Pro non forniscono il CDR. Il motore viene eseguito in-process; il documento non attendibile viene sottoposto a parsing e ricostruito sul proprio host. Confronta le edizioni e ottieni una licenza.

Cosa fa questa capacità

Il PDF supporta contenuto attivo che un visualizzatore può eseguire o su cui può agire. Un’azione ECMAScript induce un processore PDF a eseguire uno script che può modificare i valori e gli aspetti dei campi, secondo ISO 32000-2 §12.6.4. Un’azione di avvio avvia un’applicazione oppure apre o stampa un documento, secondo ISO 32000-2 §12.6.4. Gli script a livello di documento nel dizionario dei nomi vengono eseguiti automaticamente all’apertura del documento, secondo ISO 32000-2 §7.7.4. Il CDR rimuove queste superfici.

Il motore esegue una pipeline ordinata:

Parsing del PDF di input.
Controllo di ammissione — verifica che il documento rientri nel confine di accettazione (numero di oggetti, numero di pagine, dimensione del flusso decodificato e un rapporto di espansione del flusso che difende dagli input di tipo decompression-bomb). Un documento al di fuori dei limiti viene rifiutato, non sanificato. Il rifiuto è riportato in modo distinto rispetto a un risultato di sanificazione, così che la propria gestione degli errori possa distinguere i due casi.
Rilevamento delle minacce — scansione dei tipi di minaccia configurati.
Filtraggio — partizionamento degli oggetti nell’insieme sicuro e nell’insieme rimosso.
Sanificazione dei riferimenti — pulizia dei puntatori lasciati pendenti dalla rimozione.
Ricostruzione — serializzazione degli oggetti sicuri in un nuovo PDF.

I tipi di minaccia rilevabili comprendono script incorporati (e una rimozione aggressiva degli script che intercetta gli script in strutture malformate), trigger di azioni aggiuntive e di azione di apertura, azioni di avvio, azioni di go-to remoto, azioni di invio modulo e di importazione dati, file incorporati, rich media e contenuto tridimensionale, alberi di nomi di script a livello di documento, azioni di Uniform Resource Identifier (URI) esterno, dati XML Forms Architecture, campi di modulo interattivi, livelli di contenuto facoltativo non predefiniti e oggetti di firma digitale (che una ricostruzione invalida necessariamente perché i byte range non corrispondono più). Un oggetto che non può essere sottoposto a parsing è esso stesso trattato come un potenziale bypass e rimosso.

Tre policy stabiliscono le impostazioni predefinite:

Standard — rimuove i tipi di minaccia di contenuto attivo configurati e rilevabili dal motore; gli aggiornamenti incrementali vengono sempre appiattiti per difendere dallo signature-shadowing, e tale appiattimento non è configurabile in questa modalità.
Paranoid — le stesse rimozioni con limiti di risorse più stringenti.
Permissive — per le fonti attendibili: rimuove gli script e le azioni di avvio ma preserva le azioni URI, e rende configurabile l’appiattimento degli aggiornamenti incrementali.

Perché funziona così

Il CDR ricostruisce un nuovo file a partire dagli oggetti giudicati sicuri, anziché eliminare in loco le chiavi pericolose. Questa postura di tipo allow-list è la decisione portante. Un oggetto che il rilevatore non ha mai riconosciuto — compreso uno che non è riuscito a sottoporre a parsing — non sopravvive nell’output, perciò una struttura sconosciuta fallisce in modo chiuso invece di sfuggire attraverso una falla di una deny-list. Il controllo di ammissione viene eseguito per primo per la stessa ragione: un input oltre i limiti o non analizzabile viene rifiutato del tutto, mai ricostruito parzialmente. Il costo di tale sicurezza è la preservazione. La ricostruzione cambia la disposizione dei byte, invalida le firme e scarta i payload il cui tipo di minaccia viene rimosso — motivo per cui l’output è una proiezione di sicurezza, mai una copia probatoria.

Approfondimento di progettazione: Sanificare i PDF non attendibili: content disarm and reconstruction.

Prerequisiti

Installare NextPDF Core e il pacchetto Enterprise, e disporre di una licenza Enterprise attiva.
Definire il confine di accettazione per i propri input — il numero massimo di oggetti, il numero di pagine, la dimensione del flusso decodificato e il rapporto di espansione — oppure usare i limiti di una policy predefinita.
Decidere la policy: standard per l’acquisizione generale di contenuti non attendibili, paranoid per la postura più rigorosa o permissive solo per le fonti attendibili.

Configurazione

La policy è immutabile e comprende:

Tipi di minaccia da rimuovere — l’insieme che il rilevatore scansiona e che il ricostruttore rimuove.
Gestione delle azioni URI — se le azioni URI esterne vengono preservate.
Appiattimento degli aggiornamenti incrementali — sempre attivo in standard e paranoid; configurabile in permissive.
Limiti di ammissione — numero massimo di oggetti, numero di pagine, dimensione del flusso decodificato e rapporto di espansione. Questi costituiscono il confine di accettazione, non un comportamento di sanificazione; il loro superamento comporta il rifiuto del documento.

Passo per passo

Leggere i byte del PDF non attendibile.
Selezionare una policy (standard, paranoid o permissive) oppure costruirne una con limiti espliciti.
Eseguire l’operazione di sanificazione del motore con i byte e la policy.
Esaminare il risultato: se riporta non ammesso, far emergere il motivo del rifiuto; altrimenti usare i byte ricostruiti e l’elenco delle minacce rimosse.
Trattare l’output ricostruito come una proiezione sanificata, mai come una copia probatoria o di archiviazione dell’input.

<?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

Eseguire un campione che trasporta una superficie di contenuto attivo nota (per esempio uno script a livello di documento) e confermare che compaia nell’elenco delle minacce rimosse e che sia assente dall’output ricostruito.
Eseguire un documento oltre i limiti e confermare che il risultato riporti non ammesso con un motivo del rifiuto, e che i byte ricostruiti siano vuoti.
Confermare che un input firmato digitalmente abbia i propri oggetti di firma rimossi nella ricostruzione — una ricostruzione invalida la firma originale perché i byte range cambiano, perciò gli oggetti di firma obsoleti vengono rimossi per progettazione.
Aprire l’output ricostruito in un visualizzatore e confermare che nessuno script venga eseguito all’apertura.

Sicurezza e conformità

Non per uso probatorio. L’output ricostruito è una proiezione distruttiva e non reversibile. Non usarlo per la conservazione di prove legali, per il confronto di hash con l’originale né come copia di archiviazione. Conservare l’originale sotto custodia separata se serve una copia probatoria.
Ammissione prima della sanificazione. I limiti di risorse costituiscono un confine di accettazione; un documento oltre i limiti viene rifiutato, non sanificato. Riportare il rifiuto in modo distinto, così che un input oltre i limiti non venga mai scambiato per una ricostruzione pulita.
Il contenuto attivo viene rimosso. Script, azioni di avvio, alberi di nomi di script a livello di documento, file incorporati, rich media e superfici simili vengono rimossi — proprio le azioni che un visualizzatore eseguirebbe altrimenti (ISO 32000-2 §12.6.4 azione ECMAScript; azione di avvio; script a livello di documento §7.7.4).
Le firme vengono invalidate dalla ricostruzione. Poiché la ricostruzione cambia il layout dei byte, la firma originale non può più convalidarsi; gli oggetti di firma vengono rimossi anziché lasciati ingannevolmente al loro posto.
Con perdita per progettazione. I payload dei file incorporati — comprese le allegature delle fatture come Factur-X — vengono rimossi quando il relativo tipo di minaccia viene rimosso. Il CDR è una proiezione di sicurezza, non un livello di conservazione.

Questa pagina riguarda la sicurezza dei documenti. Ogni fonte normativa è parafrasata; nessun testo normativo è riprodotto.

Gestione degli errori

Errore di parsing. Un documento che non può essere sottoposto a parsing produce un risultato non ammesso con un motivo di errore di parsing anziché una ricostruzione parziale.
Input oltre i limiti. Il risultato riporta non ammesso con un motivo specifico del limite; i byte ricostruiti sono vuoti.
Oggetto non analizzabile. Un oggetto che non può essere sottoposto a parsing è trattato come un potenziale bypass e rimosso, non mantenuto silenziosamente.
Conteggio delle pagine best-effort. Il controllo di ammissione sul conteggio delle pagine è best-effort; un catalogo malformato non manda in crash la pipeline, ma i limiti sul numero di oggetti e sui flussi continuano ad applicarsi.

Confine di pubblicazione

Questa pagina documenta soltanto il comportamento osservabile dall’esterno e la superficie pubblica dell’API supportata. Percorsi di namespace interni, classi helper, tabelle di meccanismi, nomi di file dei runbook e prefissi dei ticket sono fuori ambito.

Vedere anche

Security — NextPDF Enterprise — la superficie di sicurezza Enterprise combinata.
Validation — NextPDF Enterprise — verifica di conformità di un PDF prodotto o ricostruito.
Forensics — NextPDF Enterprise — esame e tracciamento dei documenti.
Security — NextPDF Core — la superficie core di cifratura e firma.
CDR · active content · shadow attack — termini del glossario.