Content Disarm and Reconstruction (CDR)

Auf einen Blick

NextPDF Enterprise neutralisiert ein nicht vertrauenswürdiges PDF durch Content Disarm and Reconstruction (CDR): Es parst die Datei, prüft sie gegen Zulassungsgrenzen, erkennt gefährliche Merkmale, entfernt sie und baut aus den verbleibenden Objekten eine neue Datei auf. Die gefährlichen Merkmale sind aktiver Inhalt — eingebettete Skripte, Launch-Aktionen, eingebettete Dateien, Rich Media und Ähnliches —, den ein Viewer ausführen oder auf den er reagieren könnte. Diese Seite ist verhaltensorientiert: Sie legt dar, was die Engine zulässt, was sie entfernt, was sie neu aufbaut und warum die Ausgabe keine beweissichere Kopie ist.

CDR ist eine destruktive, einseitige Transformation. Die neu aufgebaute Ausgabe ist eine Sicherheitsprojektion der Eingabe, keine erhaltene oder hash-gleiche Kopie. Diese Grenze wird unter Sicherheit und Compliance dargelegt.

Die Voraussetzungen sind in der Front Matter angegeben und unter Voraussetzungen wiederholt.

Verfügbarkeit und Lizenzierung

Diese Fähigkeit wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und aktiviert sich mit einem License-Envelope der Enterprise-Stufe. Eine Bereitstellung ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. NextPDF Core und NextPDF Pro stellen kein CDR bereit. Die Engine läuft prozessintern; das nicht vertrauenswürdige Dokument wird auf Ihrem Host geparst und neu aufgebaut. Editionen vergleichen und eine Lizenz erwerben.

Was diese Fähigkeit tut

PDF unterstützt aktiven Inhalt, den ein Viewer ausführen oder auf den er reagieren kann. Eine ECMAScript-Aktion veranlasst einen PDF-Prozessor, ein Skript auszuführen, das Feldwerte und Erscheinungsbilder ändern kann, gemäß ISO 32000-2 §12.6.4. Eine Launch-Aktion startet eine Anwendung oder öffnet oder druckt ein Dokument, gemäß ISO 32000-2 §12.6.4. Dokumentebenen-Skripte im Name-Dictionary laufen automatisch, wenn das Dokument geöffnet wird, gemäß ISO 32000-2 §7.7.4. CDR entfernt diese Angriffsflächen.

Die Engine führt eine geordnete Pipeline aus:

1. Parsen des Eingabe-PDF.
2. Zulassungskontrolle — Prüfen, ob das Dokument innerhalb der Akzeptanzgrenze liegt (Objektanzahl, Seitenanzahl, dekodierte Streamgröße und ein Stream-Aufblähungsverhältnis, das gegen Dekompressionsbomben-Eingaben schützt). Ein Dokument außerhalb der Grenzen wird abgelehnt, nicht bereinigt. Die Ablehnung wird deutlich von einem Bereinigungsergebnis getrennt gemeldet, sodass Ihre Fehlerbehandlung die beiden unterscheiden kann.
3. Bedrohungen erkennen — Scannen nach den konfigurierten Bedrohungstypen.
4. Filtern — Aufteilen der Objekte in die sichere Menge und die entfernte Menge.
5. Referenzbereinigung — Bereinigen von Zeigern, die durch das Entfernen ins Leere zeigen.
6. Neu aufbauen — Serialisieren der sicheren Objekte in ein neues PDF.

Zu den erkennbaren Bedrohungstypen gehören eingebettete Skripte (und aggressives Skript-Stripping, das Skripte in fehlerhaften Strukturen erfasst), Additional-Actions- und Open-Action-Auslöser, Launch-Aktionen, Remote-Go-To-Aktionen, Formular-Submit- und Import-Data-Aktionen, eingebettete Dateien, Rich Media und dreidimensionaler Inhalt, Dokumentebenen-Skript-Name-Trees, externe Uniform-Resource-Identifier-(URI-)Aktionen, XML-Forms-Architecture-Daten, interaktive Formularfelder, nicht standardmäßige Optional-Content-Layer und Digital-Signature-Objekte (die ein Neuaufbau zwangsläufig ungültig macht, weil die Byte-Bereiche nicht mehr übereinstimmen). Ein Objekt, das nicht geparst werden kann, wird selbst als potenzielle Umgehung behandelt und entfernt.

Drei Richtlinien setzen die Standardwerte:

• Standard — entfernt die von der Engine erkennbaren, konfigurierten Aktivinhalts-Bedrohungstypen; inkrementelle Aktualisierungen werden stets abgeflacht, um gegen Signature-Shadowing zu verteidigen, und dieses Abflachen ist in diesem Modus nicht konfigurierbar.
• Paranoid — dieselben Entfernungen mit strengeren Ressourcengrenzen.
• Permissive — für vertrauenswürdige Quellen: entfernt Skripte und Launch-Aktionen, bewahrt jedoch URI-Aktionen und macht das Abflachen inkrementeller Aktualisierungen konfigurierbar.

Warum es so funktioniert

CDR baut aus den als sicher beurteilten Objekten eine neue Datei auf, statt gefährliche Schlüssel an Ort und Stelle zu löschen. Diese Allow-List-Haltung ist die tragende Entscheidung. Ein Objekt, das der Detektor nie erkannt hat — einschließlich eines, das er nicht parsen konnte —, überlebt nicht in die Ausgabe, sodass eine unbekannte Struktur ausfallsicher scheitert (fail closed), statt durch eine Deny-List-Lücke zu schlüpfen. Die Zulassungskontrolle läuft aus demselben Grund zuerst: Eine Eingabe über der Grenze oder eine nicht parsbare Eingabe wird rundheraus abgelehnt, niemals teilweise neu aufgebaut. Der Preis dieser Sicherheit ist die Erhaltung. Der Neuaufbau ändert das Byte-Layout, macht Signaturen ungültig und verwirft Nutzlasten, deren Bedrohungstyp entfernt wird — weshalb die Ausgabe eine Sicherheitsprojektion ist, niemals eine beweissichere Kopie.

Design-Hintergrund: Nicht vertrauenswürdige PDFs bereinigen: Content Disarm and Reconstruction.

Voraussetzungen

1. Installieren Sie NextPDF Core und das Enterprise-Paket und halten Sie eine aktive Enterprise-Lizenz.
2. Definieren Sie die Akzeptanzgrenze für Ihre Eingaben — die maximale Objektanzahl, Seitenanzahl, dekodierte Streamgröße und das Aufblähungsverhältnis — oder verwenden Sie die Grenzen einer voreingestellten Richtlinie.
3. Entscheiden Sie über die Richtlinie: Standard für allgemeine nicht vertrauenswürdige Aufnahme, Paranoid für die strengste Haltung oder Permissive nur für vertrauenswürdige Quellen.

Konfiguration

Die Richtlinie ist unveränderlich und trägt:

• Zu entfernende Bedrohungstypen — die Menge, nach der der Detektor scannt und die der Rebuilder entfernt.
• URI-Aktions-Behandlung — ob externe URI-Aktionen bewahrt werden.
• Abflachen inkrementeller Aktualisierungen — in Standard und Paranoid stets aktiv; in Permissive konfigurierbar.
• Zulassungsgrenzen — maximale Objektanzahl, Seitenanzahl, dekodierte Streamgröße und Aufblähungsverhältnis. Dies sind die Akzeptanzgrenze, kein Bereinigungsverhalten; ihr Überschreiten führt zur Ablehnung des Dokuments.

Schritt für Schritt

1. Lesen Sie die nicht vertrauenswürdigen PDF-Bytes.
2. Wählen Sie eine Richtlinie (Standard, Paranoid oder Permissive) oder bauen Sie eine mit expliziten Grenzen.
3. Führen Sie die Bereinigungsoperation der Engine mit den Bytes und der Richtlinie aus.
4. Prüfen Sie das Ergebnis: Meldet es „nicht zugelassen”, machen Sie den Ablehnungsgrund sichtbar; andernfalls verwenden Sie die neu aufgebauten Bytes und die Liste der entfernten Bedrohungen.
5. Behandeln Sie die neu aufgebaute Ausgabe als bereinigte Projektion, niemals als beweissichere oder Archivkopie der Eingabe.

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;
    }
}

Verifizierung

1. Führen Sie ein Beispiel mit einer bekannten Aktivinhalts-Angriffsfläche aus (zum Beispiel ein Dokumentebenen-Skript) und bestätigen Sie, dass es in der Liste der entfernten Bedrohungen erscheint und in der neu aufgebauten Ausgabe fehlt.
2. Führen Sie ein Dokument über der Grenze aus und bestätigen Sie, dass das Ergebnis „nicht zugelassen” mit einem Ablehnungsgrund meldet und die neu aufgebauten Bytes leer sind.
3. Bestätigen Sie, dass eine digital signierte Eingabe ihre Signaturobjekte im Neuaufbau entfernt bekommt — ein Neuaufbau macht die ursprüngliche Signatur ungültig, weil sich die Byte-Bereiche ändern, sodass veraltete Signaturobjekte planmäßig entfernt werden.
4. Öffnen Sie die neu aufgebaute Ausgabe in einem Viewer und bestätigen Sie, dass beim Öffnen kein Skript ausgeführt wird.

Sicherheit und Compliance

• Nicht als Beweis. Die neu aufgebaute Ausgabe ist eine destruktive, nicht umkehrbare Projektion. Verwenden Sie sie nicht zur rechtlichen Beweissicherung, zum Hash-Vergleich mit dem Original oder als Archivkopie. Bewahren Sie das Original unter separater Verwahrung auf, wenn Sie eine beweissichere Kopie benötigen.
• Zulassung vor Bereinigung. Ressourcengrenzen sind eine Akzeptanzgrenze; ein Dokument über der Grenze wird abgelehnt, nicht bereinigt. Melden Sie die Ablehnung deutlich, sodass eine Eingabe über der Grenze niemals mit einem sauberen Neuaufbau verwechselt wird.
• Aktiver Inhalt wird entfernt. Skripte, Launch-Aktionen, Dokumentebenen-Skript-Name-Trees, eingebettete Dateien, Rich Media und ähnliche Flächen werden entfernt — genau die Aktionen, die ein Viewer andernfalls ausführen würde (ISO 32000-2 §12.6.4 ECMAScript-Aktion; Launch-Aktion; Dokumentebenen-Skripte §7.7.4).
• Signaturen werden durch den Neuaufbau ungültig. Weil der Neuaufbau das Byte-Layout ändert, kann die ursprüngliche Signatur nicht mehr validieren; Signaturobjekte werden entfernt, statt irreführend an Ort und Stelle belassen zu werden.
• Verlustbehaftet per Design. Eingebettete-Datei-Nutzlasten — einschließlich Rechnungsanhängen wie Factur-X — werden entfernt, wenn ihr Bedrohungstyp entfernt wird. CDR ist eine Sicherheitsprojektion, keine Erhaltungsschicht.

Diese Seite betrifft die Dokumentsicherheit. Jede normative Quelle ist paraphrasiert; es wird kein normativer Text wiedergegeben.

Fehlerbehandlung

• Parse-Fehler. Ein Dokument, das nicht geparst werden kann, ergibt ein „nicht zugelassen”-Ergebnis mit einem Parse-Fehler-Grund statt eines partiellen Neuaufbaus.
• Eingabe über der Grenze. Das Ergebnis meldet „nicht zugelassen” mit einem grenzspezifischen Grund; die neu aufgebauten Bytes sind leer.
• Nicht parsbares Objekt. Ein Objekt, das nicht geparst werden kann, wird als potenzielle Umgehung behandelt und entfernt, nicht still beibehalten.
• Best-Effort-Seitenanzahl. Die Seitenanzahl-Zulassungsprüfung ist Best-Effort; ein fehlerhafter Katalog bringt die Pipeline nicht zum Absturz, aber die Objektanzahl- und Streamgrenzen gelten weiterhin.

Veröffentlichungsgrenze

Diese Seite dokumentiert ausschließlich extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismus-Tabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Geltungsbereichs.

Siehe auch

• Security — NextPDF Enterprise — die kombinierte Enterprise-Sicherheitsoberfläche.
• Validation — NextPDF Enterprise — Konformitätsprüfung eines erzeugten oder neu aufgebauten PDF.
• Forensics — NextPDF Enterprise — Dokumentuntersuchung und Nachverfolgung.
• Security — NextPDF Core — die Core-Verschlüsselungs- und Signaturoberfläche.
• CDR · active content · shadow attack — Glossarbegriffe.