CVE-2022-29230 : XSS dans Shopify Hydrogen

L’analyse de la CVE-2022-29230 révèle une faille critique dans la manière dont Shopify Hydrogen gère la transition entre le rendu côté serveur et l’interactivité côté client. Cette vulnérabilité, classée comme XSS, permet à un attaquant d’exécuter du JavaScript arbitraire dans le contexte du navigateur d’une victime.

Analyse de la cause racine : le fossé de l’hydratation

La vulnérabilité réside dans la phase d’hydratation du cycle de vie du rendu React. Dans les frameworks utilisant le SSR, le serveur génère le HTML initial et intègre les données d’état dans un bloc JSON (souvent via une balise <script>). Le JavaScript côté client “hydrate” ensuite cet état pour rendre la page interactive.

J’ai observé que dans les versions affectées (0.10.0 à 0.18.0), certains champs de ces données d’hydratation n’étaient pas strictement assainis. Lorsque des entrées contrôlées par l’utilisateur — telles que des paramètres d’URL ou des métadonnées — sont reflétées dans ce bloc JSON, elles peuvent briser la structure des données et injecter du code exécutable.

Attention

Les implémentations standard de CSP sont souvent insuffisantes pour mitiger cette attaque car l’injection se produit au sein du flux de données approuvé utilisé par la logique d’hydratation du framework.

Vecteur d’attaque et analyse du payload

L’attaque s’effectue via le réseau et nécessite que l’attaquant puisse influencer des données qui sont ensuite rendues sur la boutique.

Chemin d’attaque

1. Injection : l’attaquant identifie un champ (ex: requête de recherche, catégorie filtrée) reflété dans l’état JSON du serveur.
2. Livraison : l’attaquant forge une URL contenant un payload malveillant et incite la victime à cliquer dessus.
3. Exécution : au chargement de la page, le framework Hydrogen traite la chaîne JSON malveillante lors de l’hydratation, déclenchant l’exécution du script.

Exemples de payloads

Selon le point d’injection, les payloads visent généralement à briser les chaînes JSON.

• Évasion JSON : ");alert(document.domain);("
• Injection de balise : </script><script>alert(1)</script>

Artefacts forensiques

D’un point de vue Forensique, la détection repose sur l’observation des artefacts de l’échec d’hydratation.

Preuves côté client

• Inspection du DOM : présence d’attributs inattendus comme onerror ou onload dans des éléments qui devraient être statiques.
• Logs réseau : requêtes vers des domaines externes (exfiltration) déclenchées après le chargement d’une URL suspecte.

Preuves côté serveur

• Logs serveur web : requêtes HTTP contenant des caractères tels que <, >, et " dans les chaînes de requête (query strings).
• Logs Shopify Admin : modifications de Metafields contenant des scripts si l’injection a été persistante.

Logique de détection

Pour identifier les tentatives d’exploitation, je recommande les stratégies de détection suivantes.

Implémentation de la règle Sigma

Cette logique se concentre sur le repérage de motifs XSS classiques dans les logs d’accès.

title: Shopify Hydrogen XSS Attempt
id: 5f3e2a1b-c2d3-4e5f-8g9h-0i1j2k3l4m5n
description: Detects common XSS payloads in HTTP requests targeting Shopify Hydrogen storefronts.
logsource:
    category: web_server
detection:
    selection:
        url|contains:
            - '<script'
            - 'javascript:'
            - 'onerror='
            - 'onload='
            - 'alert('
    condition: selection
level: medium

Requêtes SIEM

KQL (Sentinel)

W3CIISLog
| where csUriQuery contains "<script"
    or csUriQuery contains "javascript:"
    or csUriQuery contains "alert("
| project TimeGenerated, cIP, csMethod, csUriStem, csUriQuery, scStatus

Splunk

index=web_logs
| where (uri_query="*<script*" OR uri_query="*javascript:*" OR uri_query="*alert(*")
| table _time, clientip, method, uri_path, uri_query, status

Remédiation

La seule solution fiable est la mise à jour du framework.

1. Mettre à jour Hydrogen : passer à la version 0.19.0 ou supérieure.
2. Vérifier les dépendances : s’assurer que tous les packages @shopify/hydrogen sont alignés.
3. Auditer les entrées : examiner toute logique personnalisée de récupération de données alimentant l’état serveur.