Bedrohungsmodell für die Engine

Auf einen Blick

Diese Seite beschreibt das Bedrohungsmodell für die NextPDF-Kernengine. Sie zählt die Angriffsklassen auf, die die Engine als in-scope einstuft, wenn sie von Angreifern beeinflusste Eingaben verarbeitet (HTML, CSS, SVG, Schriften, Bilder und vorhandene PDFs). Außerdem nennt sie die Standard-Haltung für jede Fähigkeit zum Laden externer Ressourcen und verweist auf den Schutzmechanismus im Code, der die jeweilige Klasse abmildert.

Abgrenzung. Ein Bedrohungsmodell dokumentiert die berücksichtigten Bedrohungen und die darauf angewandten Schutzmaßnahmen. Es behauptet nicht das Fehlen von Schwachstellen. Für eine hier nicht aufgeführte Klasse ist damit nicht bewiesen, dass sie nicht existiert — sie liegt möglicherweise außerhalb des aktuellen Geltungsbereichs des Modells. Noch nicht implementierte Funktionen durchlaufen vor ihrer Auslieferung eine formale Bedrohungsprüfung. Betrachten Sie diese Seite als Nachweis bewusster Gestaltung, nicht als Sicherheitsbeweis.

Installation

composer require nextpdf/core:^3

Die hier beschriebenen Schutzmechanismen sind Teil des Kernpakets; sie werden durch keine zusätzliche Abhängigkeit aktiviert. Sie sind standardmäßig aktiv.

Konzeptioneller Überblick

Das Modell folgt der Struktur, die der OWASP-Threat-Modeling-Prozess empfiehlt (owasp_threat_modeling#x1.x11.p6): Das System wird in die Punkte zerlegt, an denen nicht vertrauenswürdige Eingaben eine Vertrauensgrenze überschreiten; die Bedrohungen an jeder Grenze werden aufgezählt und die jeweilige Schutzmaßnahme wird festgehalten.

Die primäre Vertrauensgrenze der Engine ist die Dokument-Ingestion: jede Stelle, an der extern erstellte Inhalte — ein entferntes Stylesheet, eine @font-face-Quelle, ein <image href>, eine eingebettete XML-Rechnung, ein zu prüfendes PDF — die Engine anweisen könnten, etwas zu laden, zu parsen oder zu dekomprimieren. Das leitende Prinzip ist Deny-by-default: Jede Fähigkeit zum Laden externer Ressourcen ist AUS, bis der Aufrufer sie über ein Policy-Objekt ausdrücklich aktiviert. Das ist die Least-Functionality-Baseline von NIST SP 800-53 Rev. 5 CM-7 (nist_sp_800_53r5#x4.x182.p14), angewandt auf eine Rendering-Engine: Die strengste Einstellung ist der Standardwert des Konstruktors. Das Freischalten einer Fähigkeit ist eine ausdrückliche Entscheidung des Aufrufers.

API-Oberfläche

Das Bedrohungsmodell ist selbst keine API. Die Policy-Objekte, die es ausdrücken, sind auf den Modul-Seiten dokumentiert; die vertrauensrelevanten Einstiegspunkte sind der Vertrag für die Policy externer Ressourcen (ExternalResourcePolicyInterface, mit DefaultExternalResourcePolicy als Deny-all-Standard) sowie die URL- und XML-Schutzmechanismen (UrlValidator, XmlGuard). Diese Seite verweist auf deren Verhalten; sie dokumentiert die Signaturen nicht erneut.

Code-Beispiel — Schnellstart

Die sichere Haltung ist der Standard. Es ist kein Code nötig, um sie zu erhalten:

<?php

declare(strict_types=1);

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

use NextPDF\Html\DefaultExternalResourcePolicy;

// Out of the box: @font-face blocked, @import blocked, background-image
// blocked, SVG external refs blocked. A document that tries to fetch a
// remote resource gets a system-font fallback or an ignored rule — not an
// outbound request.
$policy = new DefaultExternalResourcePolicy();

Code-Beispiel — Produktion

Das Freischalten einer Fähigkeit erfolgt bewusst und eng begrenzt. Ein Aufrufer in Produktion, der eine über ein CDN gehostete Webschrift über HTTPS zulassen muss, entscheidet sich ausdrücklich dafür und grenzt diese Freigabe ein:

<?php

declare(strict_types=1);

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

use NextPDF\Html\DefaultExternalResourcePolicy;

// Explicit, scoped opt-in. The HTTPS scheme is required; size and glyph
// caps still apply; the URL still passes the SSRF guard before any fetch.
$policy = (new DefaultExternalResourcePolicy())
    ->withFontFaceAllowed(['https']);

Sonderfälle & Stolperfallen

Nicht implementiert ist nicht dasselbe wie zufällig sicher. Fähigkeiten wie CSS background-image url() sind nicht implementiert. Sie bringen daher derzeit keinerlei Angriffsfläche mit. Sie sind jedoch so dokumentiert, dass sie vor jeder künftigen Implementierung ein formales Bedrohungs-Gate durchlaufen müssen. Das Fehlen von Code ist heute die Schutzmaßnahme, keine dauerhafte Garantie.
DNS-Rebinding ist ein bewegliches Ziel. UrlValidator löst den Hostnamen auf und gibt die aufgelöste IP zurück, damit der Aufrufer die Verbindung pinnen kann (CURLOPT_RESOLVE) und das Validate-then-fetch-TOCTOU-Fenster geschlossen wird. Das ist eine Best-Effort-Verteidigung, keine absolute. Ein Betreiber hinter einem freizügigen Egress-Proxy kann weiterhin interne Hosts erreichen, die die Bibliothek nicht sehen kann.
Berechtigungs-Bits sind keine Zugriffskontrolle. Ein Dokument, das „das Kopieren blockiert“, verlässt sich auf die Kooperation des Readers, nicht auf Durchsetzung. Das behandelt das Sicherheitsmodell. Es wird hier hervorgehoben, weil es ein häufiges Missverständnis bei Bedrohungsmodellen ist.

Performance

Die Schutzmechanismen sind darauf ausgelegt, schnell abzubrechen und den Arbeitsaufwand zu begrenzen: Der XML-Schutzmechanismus weist DOCTYPE vor dem Parsen ab und begrenzt die Eingabegröße; der Bildpfad erzwingt vor der Dekompression eine Megapixel- und Byte-Obergrenze; der URL-Schutzmechanismus weist anhand von scheme/host ab, bevor ein Socket geöffnet wird. Die Kosten des sicheren Standards bestehen in einer abgewiesenen, nicht in einer langsamen Anfrage.

Sicherheitshinweise

Die berücksichtigten Angriffsklassen und ihre Schutzmaßnahmen im Code:

Bedrohungsklasse (CWE / OWASP)	Vektor in einer PDF-Engine	Schutzmechanismus im Code
SSRF (OWASP Top 10 2025; `owasp_top10_2025#x3.x1.p26`)	Verweise über `@font-face`/`@import`/`url()` auf `169.254.169.254` oder einen internen Host; TSA/OCSP/CRL-Fetcher	`UrlValidator::validateExternalUrl()` blockiert private/reserved/Loopback-/Link-local-Bereiche und Cloud-Metadaten-Endpunkte, weist gefährliche Schemata ab, löst DNS auf und gibt die IP für das Connection-Pinning zurück
XXE (`cwe_top25_2025#x28.x2.p42`)	Externe Entitäten / DOCTYPE in einer eingebetteten XML-Rechnung oder einem XMP-Paket	`XmlGuard::loadXml()` erzwingt `LIBXML_NONET` und weist jede DOCTYPE-Deklaration grundsätzlich ab, zusätzlich nach XML 1.0 verbotene Steuerzeichen und eine Obergrenze für die Eingabegröße
Dekompressionsbombe	1×1-Bild, das eine 100-MP-Nutzlast verbirgt; übergroße WOFF2	Der Bildpfad erzwingt vor der Dekompression eine Megapixel-Obergrenze und eine Byte-Obergrenze; der Schriftpfad begrenzt Dateigröße und Glyphenanzahl
Path-Traversal	`file:///etc/passwd` über eine Schrift oder ein SVG-`src`	Externe Ressourcen standardmäßig Deny-all; lokale Dateipfade werden bei ausdrücklicher Aktivierung über `realpath()` gegen eine Verzeichnis-Allowlist aufgelöst
Content-Injection	Manipulierte Zeichenkette, die aus einem PDF-Operator ausbricht; `data:`/`javascript:`-href	PDF-String-Escaping bei der Ausgabe; Schema-Allowlist + href-Bereinigung bei Annotationen

Die Standardwerte bilden eine Deny-all-Haltung für externe Ressourcen: Schrift, @import, background-image und externe SVG-Referenzen sind aus, bis der Aufrufer sich pro Schema dafür entscheidet, gemäß der Abdeckungsmatrix der Sicherheitseigenschaften, die parallel zum Code gepflegt wird.

Diese Seite dokumentiert berücksichtigte Bedrohungen. Sie ist kein Penetrationstestbericht und behauptet nicht, dass die aufgeführten Schutzmaßnahmen vollständig sind oder dass keine andere Schwachstellenklasse zutrifft.

Konformität

Kein Konformitätsprofil. Das Bedrohungsmodell orientiert sich am OWASP-Threat-Modeling-Prozess und an der CWE-Top-25-Schwachstellentaxonomie (cwe_top25_2025#x28.x2.p42); es beansprucht keine Konformität mit einem Sicherheitszertifizierungsschema. Eine unabhängige Bewertung ist Gegenstand eines Audits, nicht dieses Dokuments.