flawopen.com/Ruby YAML/Ruby YAML

Ist YAML.load bei nicht vertrauenswürdigen Eingaben sicher?

# Psych < 4: YAML.load used unsafe
# object construction by default.
YAML.load(params[:config])

# Every Psych version: explicitly unsafe.
YAML.unsafe_load(user_input)
Psych.unsafe_load(user_input)

# Marshal has no restricted safe-load API.
Marshal.load(cookie_value)

# Explicit restricted types; keep this list minimal.
require "yaml"
require "date"

data = YAML.safe_load(
  input,
  permitted_classes: [Date],
  permitted_symbols: [],
  aliases: false
)

# For ordinary external data, prefer JSON and
# validate its shape, values, and input size.
data = JSON.parse(input)

Warum YAML gefährlich sein kann

YAML-Tags können von Psych in Ruby-Objekte umgewandelt werden. Bei unsicherem Laden kann ein getaggtes Dokument die Konstruktion einer Klasse anfordern und Werte für deren serialisierten Zustand liefern; die Auswirkungen hängen von verfügbaren Klassen und deren Verhalten ab. So entstehen Deserialisierungs-Gadget-Ketten. Laden Sie nicht vertrauenswürdiges YAML sicher und validieren Sie die resultierenden Daten zusätzlich. Das allgemeine Risiko besteht auch bei Python pickle, PHP unserialize und Ruby-Marshal.load.

Rails-Anwendungen und andere Dienste laden oft viele Abhängigkeiten. Dadurch stehen einer unsicheren Deserialisierungskette mehr Klassen und Verhaltensweisen zur Verfügung. Das hängt von der konkreten Bereitstellung ab und gilt nicht pauschal für jede Rails-Anwendung oder YAML-Datei.

Warum die Versionsänderung für Verwirrung sorgte

Psych 4 änderte YAML.load so, dass standardmäßig sicher geladen wird, und führte unsafe_load für das frühere Verhalten mit Objektkonstruktion ein. Ruby 3.1 enthielt Psych 4, Anwendungen können jedoch eine andere Psych-Gem-Version auswählen. Prüfen Sie deshalb die aufgelöste Abhängigkeit und Runtime, nicht nur die Ruby-Version. Da sicheres Laden anwendungsspezifische Klassen oder Aliase ablehnen kann, migrieren Sie mit einer minimalen expliziten Zulassungsliste, statt zu unsafe_load zu wechseln.

Führt ein Upgrade zu unsafe_load, behandeln Sie den Aufruf als Befund, wenn Eingaben außerhalb der vertrauenswürdigen Bereitstellungsgrenze beeinflusst werden können. Verwenden Sie bevorzugt safe_load mit der kleinsten nötigen Liste für permitted_classes; erweitern Sie sie nicht nur, um Kompatibilitätsfehler zu unterdrücken.

FAQ

Ein separates Ruby-Risiko: Marshal.load

Unabhängig von YAML dokumentiert Ruby, dass Marshal.load nahezu jede im Prozess geladene Klasse wiederherstellen kann und bei nicht vertrauenswürdigen Daten zu Remote-Codeausführung führen kann. Bewahren Sie Marshal-Daten innerhalb einer Vertrauensgrenze auf und deserialisieren Sie niemals vom Benutzer gelieferte oder von Angreifern beeinflusste Bytes.

Quellen

• Ruby documentation — Psych (YAML)
• Psych 4.0 — Ruby 3.1 API documentation
• Ruby documentation — Marshal security considerations
• CVE-2024-35221 — YAML alias denial of service in RubyGems metadata
• CWE-502 — Deserialization of Untrusted Data
• Is Python's pickle safe for untrusted data?
• Is PHP's unserialize() safe on user input?
• Ruby-Dokumentation — Sicherheitshinweis zu Marshal.load