XML prüfen

Zwei verschiedene Hürden – und welche hier geprüft wird

XML kennt zwei Stufen der Korrektheit, und sie werden ständig verwechselt. Wohlgeformt bedeutet, dass das Dokument die Syntax von XML selbst einhält: ein Wurzelelement, jedes Tag geschlossen, korrekte Verschachtelung, zulässige Zeichen, korrekt maskierte kaufmännische Und-Zeichen und spitze Klammern, Attributwerte in Anführungszeichen, eindeutige Attributnamen innerhalb eines Elements. Gültig bedeutet mehr – dass das Dokument zusätzlich einem bestimmten Schema entspricht, mit den richtigen Elementen in der richtigen Reihenfolge und den richtigen Arten von Werten. Diese Seite prüft Ersteres. Jeder XML-Parser lehnt ein Dokument ab, das daran scheitert – es ist also die Prüfung, die entscheidet, ob eine Datei überhaupt gelesen werden kann.

Die Fehler sind vorhersehbar. Ein nicht maskiertes & ist mit großem Abstand der häufigste – es leitet eine Entitätsreferenz ein, sodass eine URL mit Query-String, die direkt in ein Element eingefügt wird, das Dokument zerstört. Ein einzelnes < im Text bewirkt dasselbe. Danach kommen nicht passende oder nicht geschlossene Tags, in falscher Reihenfolge geschlossene Elemente, zwei Wurzelelemente und ein verirrtes Steuerzeichen, das XML überhaupt nicht zulässt, obwohl es unsichtbar in der Datei steht.

Eine DTD oder ein Schema wird bewusst nie abgerufen – das ist eine Sicherheitseigenschaft, keine fehlende Funktion. Ein XML-Dokument kann eine externe Entität benennen, und ein Parser, der sie auflöst, ruft ab, worauf sie zeigt – eine Datei auf der Festplatte, eine Adresse in einem internen Netzwerk. Das ist die XML-External-Entity-Schwachstelle, eine der am häufigsten ausgenutzten Fehlerklassen überhaupt, und der einzige vollständige Schutz besteht darin, solche Entitäten nicht aufzulösen. Deshalb greift hier nichts nach außen, und der Preis dafür ist, dass die Validierung gegen ein Schema nicht zum Umfang gehört.

Sie erhalten genau Zeile und Spalte, an der das Parsen abgebrochen ist. Wie bei jedem Parser ist das die Stelle, an der das Dokument keinen Sinn mehr ergab, nicht die Stelle des Fehlers: Ein nicht geschlossenes Tag wird meist beim unerwarteten schließenden Tag gemeldet, das darauf folgt – manchmal Hunderte Zeilen später. Die gemeldete Position ist der Punkt, ab dem Sie nach oben suchen sollten, nicht der, an dem Sie ändern müssen.

Wenn Sie etwas anderes brauchen

Für die Validierung gegen ein Schema ist xmllint das Referenz-Tool: xmllint --noout --schema schema.xsd file.xml für XSD, --relaxng für RELAX NG und --noout --valid für eine DTD. Es meldet jeden Verstoß, statt beim ersten aufzuhören – genau das, was Sie wollen, wenn ein Dokument wirklich falsch und nicht bloß kaputt ist.

Bei allem, was nicht vertrauenswürdige Eingaben betrifft, zählt die Parser-Konfiguration mehr als der Validator. Schalten Sie die Auflösung externer Entitäten und die DTD-Verarbeitung in Ihrer Sprache ausdrücklich ab – defusedxml in Python, LIBXML_NONET in PHP, Secure Processing in Java –, denn mehrere verbreitete Parser lösen Entitäten standardmäßig noch immer auf, und genau in dieser Voreinstellung steckt die Schwachstelle.