Zusammenfassung

  • Der YAML-LD-1.0-Arbeitsentwurf des W3C vom 24. September 2026 benennt nun in seinem nicht normativen Sicherheitsteil zwei Gefahren: die Vervielfachung durch Aliasse und mögliche Codeausführung durch bestimmte YAML-Tags.
  • Diese Gefahren sind nicht neu. RFC 9512 behandelte sie bereits 2024; gegenüber der Fassung vom 20. September wurde die Warnung im YAML-LD-Text selbst präziser.
  • Eine gültige Repräsentation in JSON-LD sagt noch nichts über Speichergrenzen und Konstruktor-Einstellungen einer bestimmten Parser-Bibliothek aus.

Bei einem Datenaustausch wirkt eine YAML-LD-Datei oft erfreulich übersichtlich. Wiederkehrende Definitionen stehen nur einmal im Text; Aliasse verweisen darauf. Die ausführende Software sieht eine andere Aufgabe. Nach dem Entwurf wird jeder Aliasverweis beim Aufbau der internen JSON-LD-Repräsentation als Kopie des Zielknotens behandelt. Ein kleines Eingabedokument kann dadurch erheblich mehr Arbeit auslösen als seine Zeilenzahl erwarten lässt.

Die Arbeitsgruppe JSON-LD hat diese Differenz am 24. September ausdrücklich in den Sicherheitsteil aufgenommen. Die Fassung vom 20. September verwies dort lediglich allgemein auf JSON-LD und das Suffix +yaml. Jetzt führt der Entwurf RFC 9512 an und erklärt, dass auch ein azyklischer YAML-Graph bei Aliasauflösung zu einem sehr viel größeren JSON-LD-Baum anwachsen kann. Außerdem können Tags in einigen Parsern unerwartete Codeausführung auslösen; !!python/object ist das genannte Beispiel. Der Abschnitt bezeichnet sich ausdrücklich als nicht normativ.

Weder der Angriffstyp noch die technische Warnung entstanden erst mit dieser Revision. Das im Februar 2024 veröffentlichte IETF-Dokument RFC 9512 registrierte den YAML-Medientyp und das strukturierte Suffix und behandelte schon Ressourcenerschöpfung und beliebige Codeausführung. Die W3C-Fassung macht den Bezug für YAML-LD unmittelbarer. Sie berichtet keinen Vorfall bei einem benannten Anbieter, misst keine Häufigkeit und verschärft hier keine verbindliche Schutzanforderung. Ein Working Draft kann überarbeitet werden und ist keine Empfehlung oder Billigung durch das W3C und seine Mitglieder.

YAML-LD will Linked Data in der gut lesbaren YAML-Syntax darstellen und semantisch ohne Verlust nach JSON-LD überführen. Der Entwurf erlaubt Anker und Aliasse in der Serialisierung, verbietet aber Zyklen im Repräsentationsgraphen. Ankernamen und die Aliasstruktur überleben die Konvertierung nicht als semantische Daten. Gerade diese Trennung erklärt, warum die korrekte Behandlung eines Referenzgraphen noch keine Obergrenze für die Größe seiner entfalteten Kopien liefert.

Der Text setzt weitere Konformitätsbedingungen: UTF-8, Verarbeitung nach YAML 1.2 oder einer kompatiblen späteren Fassung, Zeichenketten als Mapping-Schlüssel und die aufgeführten Testsuiten. Er warnt auch vor Bibliotheken mit YAML-1.1-Verhalten, die etwa no und on als boolesche Werte lesen. Das sind relevante Regeln für ein einheitliches Datenergebnis. Sie legen aber weder das Ressourcenbudget einer konkreten Anwendung noch den sicheren Modus eines sprachspezifischen Tag-Konstruktors fest.

Wer fremde Dateien annimmt, sollte deshalb zwei Freigaben unterscheiden. Die erste betrifft die semantische Eignung der Daten; die zweite die Bibliothek, ihre Version, erlaubte Tags, Grenzen der Aliasentfaltung und den Umgang mit unvertrauenswürdigen Eingaben. Ein solcher Prüfvermerk ist ein Vorschlag von Daniel Kade, keine vom W3C vorgeschriebene Akte. Die Aussage „YAML-LD-konform“ beantwortet die Frage nach der Bedeutung des erzeugten Ergebnisses, nicht nach der Sicherheit jedes Weges dorthin.

Quellen