flawopen.com/Ruby YAML/Ruby YAML

YAML.load est-il sûr avec des entrées non fiables ?

# 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)

Pourquoi YAML peut être dangereux

YAML contient des balises que Psych peut convertir en objets Ruby. Avec un chargement non sécurisé, un document balisé peut demander la construction d’une classe et fournir des valeurs pour son état sérialisé ; l’impact dépend des classes disponibles et de leur comportement. C’est le principe des chaînes de gadgets de désérialisation. Utilisez un chargement sûr pour les YAML non fiables et validez séparément les données obtenues. Le risque général existe aussi avec Python pickle, PHP unserialize et Marshal.load en Ruby.

Rails et d’autres applications peuvent charger de nombreuses dépendances, ce qui élargit l’ensemble des classes et comportements accessibles à une chaîne de désérialisation non sécurisée. Cela dépend du déploiement ; ce n’est pas une propriété de toutes les applications Rails ni de tout document YAML.

Pourquoi le changement de version a créé de la confusion

Psych 4 a modifié YAML.load pour utiliser un chargement sûr par défaut et a introduit unsafe_load pour conserver le comportement antérieur de construction d’objets. Ruby 3.1 incluait Psych 4, mais une application peut choisir une autre version de la gem Psych ; vérifiez la dépendance résolue et le runtime, pas seulement la version de Ruby. Comme le chargement sûr peut refuser des classes propres à l’application ou des alias, migrez avec une liste d’autorisation explicite et minimale au lieu de passer à unsafe_load.

Si une mise à niveau introduit unsafe_load, signalez cet appel lorsque l’entrée peut être contrôlée hors de la frontière de déploiement fiable. Préférez safe_load avec la liste minimale requise de permitted_classes ; ne l’élargissez pas uniquement pour masquer des erreurs de compatibilité.

FAQ

Autre risque Ruby : Marshal.load

À la différence de YAML, la documentation Ruby indique que Marshal.load peut reconstruire presque toute classe chargée dans le processus et entraîner une exécution de code à distance si les données ne sont pas fiables. Gardez les données Marshal dans une frontière de confiance ; ne désérialisez jamais des octets fournis par l’utilisateur ou influencés par un attaquant.

Références

• 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?
• Documentation Ruby — avertissement de sécurité sur Marshal.load