Zum Inhalt springen

compat-legacy – Sicherheit und Betrieb

Der Adapter erbt das Sicherheitsmodell der NextPDF-Engine und ergänzt eine kleine Anzahl bewusster Härtungen gegenüber dem Legacy-TCPDF 6.2.13. Diese Seite legt präzise dar, was verfügbar ist und was nicht – ohne Übertreibung. Lesen Sie den Abschnitt zur Signierung sorgfältig – sein Geltungsbereich ist bewusst eng gefasst.

Drei historische Verhaltensweisen von TCPDF 6.2.13 wurden aus Sicherheitsgründen geändert und lassen sich nicht auf die unsichere Form zurückkonfigurieren:

AspektLegacy-TCPDF 6.2.13Adapter
FehlerbehandlungError() ruft die() auf und beendet den ProzessError() wirft RuntimeException. Der Fehler ist beobachtbar und abfangbar; der Prozess wird nicht stillschweigend beendet.
HTML-AusführungEine Hintertür konnte PHP aus dem Markup ausführenDie Konstante K_TCPDF_CALLS_IN_HTML ist fest auf false gesetzt; Markup kann keine PHP-Ausführung auslösen.
Direkte AusgabeOutput() gibt in den aktiven Ausgabepuffer ausDie Ausgabe wird über eine sichere Ziel-Bridge geleitet. Sie verunreinigt keinen vom Aufrufer kontrollierten Ausgabepuffer.

Die geänderte Fehlerbehandlung folgt dem Grundsatz, dass ein Aufrufer einen Fehler beobachten können muss, statt dass der Prozess einfach beendet wird. OWASP ASVS 5.0 §16.5.3 verlangt, dass eine Anwendung kontrolliert und sicher fehlschlägt und Fail-Open-Zustände verhindert. Die Umstellung von »die« auf »throw« setzt diesen Grundsatz um. Die HTML-Härtung entfernt eine Senke für Codeausführung. Behandeln Sie jeden Legacy-Code, der vom alten Verhalten abhing, als Defekt, der im Rahmen von /integrations/tcpdf-compat/migration/ zu beheben ist. Der angeheftete Klausel-Digest befindet sich im Front-Matter der Seite unter citations.

Der Adapter stellt TCPDFs SetProtection() bereit. Sie delegiert an den Standard-Security-Handler der NextPDF-Engine.

  • Der Standard-Handler verwendet AES-256. Der Legacy-Parameter $mode wird aus Kompatibilitätsgründen in der Methodensignatur akzeptiert und ignoriert – über diese Methode lässt sich keine schwächere Chiffre auswählen. Bei aktiviertem Strict-Modus wirft ein von der Vorgabe abweichender $mode eine Ausnahme, sodass die Migration ihn zwingend berücksichtigen muss (geprüft in tests/Unit/Compat/Tcpdf/TcpdfStrictModeTest.php).
  • Wird kein Eigentümerpasswort angegeben, erzeugt der Adapter ein kryptografisch starkes, zufälliges Eigentümerpasswort, statt das Benutzerpasswort wiederzuverwenden. Dadurch können Inhaber von Zugriffsrechten auf Benutzerebene nicht die Kontrolle auf Eigentümerebene über das Dokument erlangen.
  • Zertifikatsbasierte (Public-Key-)Verschlüsselung erfolgt nicht über SetProtection(); der Parameter $pubkeys wird ignoriert. Verwenden Sie den modernen Einstiegspunkt für Public-Key-Verschlüsselung, den der Adapter bereitstellt (setPublicKeyEncryption()) und der an die Engine delegiert.

Das Verschlüsselungsverhalten entspricht dem Standard-Security-Handler, der in ISO 32000-2 §7 beschrieben ist. Diese Klausel definiert die Einträge des Verschlüsselungs-Dictionarys und den AES-256-Standard-Handler, den die Engine verwendet. Diese Dokumentation behauptet nicht, dass die Ausgabe „standardmäßig sicher“ oder „manipulationssicher“ ist. Sie nennt die verwendete Chiffre und das Verhalten des Eigentümerpassworts – also genau das, was der Code tut. Der angeheftete Klausel-Digest befindet sich im Front-Matter der Seite unter citations.

examples/security-encryption.php
<?php
declare(strict_types=1);
require __DIR__ . '/vendor/autoload.php';
use NextPDF\Compat\Tcpdf\TCPDF;
$pdf = new TCPDF();
$pdf->AddPage();
$pdf->SetFont('helvetica', '', 12);
$pdf->Cell(0, 10, 'Encrypted document');
// User password set; owner password auto-generated (strong, random).
$pdf->SetProtection([], 'user-secret');
$pdf->Output(__DIR__ . '/encrypted.pdf', 'F');

Digitale Signaturen – Geltungsbereichserklärung

Abschnitt betitelt „Digitale Signaturen – Geltungsbereichserklärung“

Lesen Sie diesen Abschnitt wörtlich. Er ist bewusst konservativ formuliert.

  • Die TCPDF-Legacy-Methoden setSignature() und addEmptySignatureAppearance() sind im Adapter auf der Core-Engine nicht implementiert. Im Standardmodus tun sie nichts und werfen im Strict-Modus TcpdfNotImplementedException.
  • Digitales Signieren ist keine Fähigkeit der Core-Distribution über diesen Adapter. Baseline-Signaturunterstützung ist auf eine kommerzielle NextPDF-Edition beschränkt.
  • Ist eine kommerzielle Edition vorhanden, stellt der Adapter einen modernen Signatur-Einstiegspunkt (setSignatureV2()) bereit, der an die Engine delegiert. Sein Standardprofil ist das Baseline-(B-B)-Profil.
  • Diese Dokumentation erhebt keinerlei Anspruch darauf, dass irgendeine Edition über diesen Adapter zeitgestempelte Signaturprofile oder Profile für Langzeitvalidierung oder Archivierung erzeugt. Insbesondere sichert sie kein B-T-, B-LT- oder B-LTA-Verhalten zu. Die PAdES-Baseline-Spezifikation §6.1 definiert vier unterschiedliche Baseline-Stufen – B-B, B-T, B-LT und B-LTA – jeweils mit eigenen Anforderungen. B-B ist die Baseline-Stufe; die höheren Stufen (Zeitstempel, Langzeit, Archivierung) sind eigenständige, anspruchsvollere Profile. Nur die B-B-Baseline fällt in den dokumentierten Geltungsbereich dieser Kompatibilitätsschicht. Die höheren Stufen liegen ausdrücklich außerhalb des Geltungsbereichs und werden hier für keine Edition zugesichert. Der angeheftete Klausel-Digest befindet sich im Front-Matter der Seite unter citations.
  • Es wird an keiner Stelle behauptet, dass eine Signatur „zertifiziert“, „garantiert“, „rechtsgültig“ oder „eIDAS-qualifiziert“ sei. Korrektheit der Signierung, Trust-Anchor-Richtlinie und Rechtsgültigkeit liegen in der Verantwortung der signierenden Edition und der PKI des Aufrufers, nicht dieser Kompatibilitätsschicht.

Falls Ihre Migration Signierung erfordert, behandeln Sie dies als separaten Arbeitsstrang: Setzen Sie die moderne Signatur-API mit einer kommerziellen Edition ein und validieren Sie die erzeugte Signatur mit einem unabhängigen Prüfer. Verlassen Sie sich nicht auf den TCPDF-Aufruf setSignature() – er ist hier eine No-Op.

Die Legacy-Methode setTimeStamp() wird aus Kompatibilitätsgründen in der Methodensignatur akzeptiert und gibt einen Hinweis aus; über diesen Adapter erzeugt sie keine zeitgestempelte Signatur.

Das pdfa-Flag des Konstruktors wird aus Kompatibilitätsgründen in der Methodensignatur akzeptiert. PDF/A-Archivierungskonformität erfordert eine kommerzielle NextPDF-Edition. Der Adapter stellt enablePdfA() bereit, das an die Engine delegiert; die Engine gibt einen umsetzbaren Konfigurationsfehler zurück, wenn die erforderliche Edition fehlt. Der Adapter erzeugt nicht stillschweigend eine nicht konforme Datei, die vorgibt, PDF/A zu sein.

Die Ausgabe ist stets PDF 2.0 (ISO 32000-2). ISO 32000-2 §7.5.2 legt fest, dass ein konformer Writer die Dokumentversion als 2.0 ausweist und sie beim Speichern nicht auf eine ältere Version herabsetzt. setPDFVersion() kann daher keine ältere Version anvisieren (siehe /integrations/tcpdf-compat/method-coverage/ §4). Der angeheftete Klausel-Digest befindet sich im Front-Matter der Seite unter citations.

  • Keine Prozessbeendigung. Da Error() statt die() wirft, umschließen Sie Render-Einstiegspunkte mit try/catch und bilden Sie Fehler auf den Fehlervertrag Ihrer Anwendung ab. Gehen Sie nicht davon aus, dass ein fehlgeschlagenes Rendering die Anfrage beendet.
  • Sicherheit des Ausgabepuffers. Output() mit S gibt Bytes zurück; mit F schreibt es eine Datei; mit E gibt es einen Base64-MIME-Body zurück; mit I/D leitet es über den Ausgabepfad der Engine. Bevorzugen Sie in Workern und HTTP-Handlern S oder F, damit Sie die Antwort selbst steuern – siehe /integrations/tcpdf-compat/production-usage/.
  • Der Strict-Modus ist keine Produktionseinstellung. Beschränken Sie ihn auf einen CI-/Audit-Job. Eine Ausnahme in einem produktiven Render-Pfad ist schlimmer als ein stillschweigend herabgestufter Parameter.
  • Konstanten-Hygiene. Definieren Sie PDF_*-/K_*-Konstanten vor der ersten Adapter-Konstruktion. Die beiden gehärteten Flags (K_TCPDF_CALLS_IN_HTML, K_TCPDF_THROW_EXCEPTION_ERROR) lassen sich nicht lockern; versuchen Sie es nicht.
  • Zufällige Eigentümerpasswörter. Falls Sie sich auf ein deterministisches Eigentümerpasswort verlassen, legen Sie es ausdrücklich fest. Andernfalls wird pro Dokument ein starkes, zufälliges Eigentümerpasswort erzeugt, das nicht wiederherstellbar ist.
  • Bei Bild-Methoden wird ein Stream-Wrapper-Pfad vor jedem Dateisystemzugriff abgelehnt. Die Bildtyp-Erkennung (TcpdfImages::getImageFileType) behandelt jeden scheme://-Pfad – phar://, php:// und andere PHP-Stream-Wrapper – als Wrapper und überspringt die file_get_contents-/getimagesize-Prüfung; stattdessen greift sie auf eine reine Erkennung anhand der Dateiendung zurück. Dies schließt einen Phar-Metadaten-Deserialisierungsvektor auf dem PHP-7.4-Backport-Ziel; die Einbettung des Wrapper-Pfads selbst wird von der Engine abgelehnt.
  • Darüber hinaus validiert oder bereinigt der Adapter die an Bild- oder Ausgabemethoden übergebenen Dateipfade nicht über das hinaus, was die Engine tut. Behandeln Sie vom Aufrufer bereitgestellte Pfade und URLs an der Anwendungsgrenze als nicht vertrauenswürdig.
  • An die HTML-Methoden übergebenes HTML wird von der Engine gerendert, nicht von einem TCPDF-HTML-Parser. Die Legacy-Senke für PHP-Ausführung ist geschlossen, doch vom Aufrufer bereitgestelltes HTML sollte weiterhin als nicht vertrauenswürdige Eingabe behandelt werden.
  • Die Verschlüsselung schützt die Vertraulichkeit des Dokuments im Ruhezustand gemäß dem Standard-Handler. Sie ist kein Ersatz für Transportsicherheit oder Zugriffskontrolle in Ihrer Anwendung.
  • /integrations/tcpdf-compat/method-coverage/ – genaues Verhalten von SetProtection(), setSignature()
  • /integrations/tcpdf-compat/configuration/ – die beiden gehärteten, nicht konfigurierbaren Flags
  • /integrations/tcpdf-compat/production-usage/ – Worker, Puffer, Fehlerbehandlung
  • docs/TCPDF_COVERAGE.md – maßgebliche Abdeckungsmatrix
  • Paket-NOTICE – Erklärung zur unabhängigen Implementierung