SEC-01 — La redirection de connexion permet une XSS DOM

Gravité historique : Élevée. Classification : CWE-79.

État au 14 septembre 2026 : Corrigé dans le code suivi de check_secu. safeLoginRedirect n'accepte que les chemins internes commençant par un seul slash et rejette antislashs et caractères de contrôle ; la validation est appliquée par le contexte actif. Déploiement inconnu.

Executive Summary

Un attaquant sans compte peut envoyer à une victime un lien de connexion contenant un paramètre redirect malveillant. La victime doit ouvrir ce lien et réussir sa connexion. Le contexte actif utilise des cookies HttpOnly : il ne faut donc pas décrire ce problème comme une lecture automatique de jetons dans localStorage.

Cette fiche repose sur la relecture du code historique accessible et du correctif courant, ainsi que des preuves documentées lors des passes précédentes. Elle ne constate aucun incident réel. La plus ancienne version ici vérifiée est le snapshot 8446f87 ; les corrections historiques figurent dans c09b8be. Aucun tag local ni version déployée n'a permis d'établir une première release vulnérable ou corrigée. Voir METHODOLOGIE.md.

Background

La destination fournie par un lien de connexion est une donnée non fiable. Seule une navigation interne au produit doit être permise une fois la session ouverte ; HttpOnly protège la lecture du cookie, pas toutes les actions d’un script de même origine.

Vulnerability Details

La page app/[locale]/login/page.tsx lit searchParams.get('redirect'), puis transmet cette valeur au login du contexte. Après apiLogin et le chargement du profil, AuthProvider passe la destination directement à router.push. Le contrôle manquant est une validation de destination au moment où la session devient active. Un schéma actif comme javascript: ne doit jamais être traité comme une navigation métier. Le rapport initial a inspecté le chemin dans Next installé ; il ne contient pas de démonstration d'exécution dans un navigateur réel. La fiche conserve donc la distinction entre chemin de code confirmé et exécution navigateur non reproduite.

Extrait historique vérifié, apps/frontend/src/lib/context/auth-context.tsx, lignes 105–110 du snapshot préaudit :

    try {
      await apiLogin({ email, password, rememberMe });
      // Fetch complete user profile after login (session lives in httpOnly cookies)
      const currentUser = await getCurrentUser();
      setUser(currentUser);
      router.push(redirectTo);

Les numéros ci-dessus décrivent le snapshot ancien ; les liens suivants ouvrent les fichiers courants, où les lignes peuvent avoir changé.

Sources à examiner ensemble :

La dépendance locale relue pendant cette rédaction est Next 14.2.35. Dans dist/client/components/app-router.js, useNavigate construit une URL ; le reducer de navigation envoie les URLs externes vers handleExternalUrl, puis le mode MPA utilise window.location.assign(canonicalUrl) ou replace. C’est le parcours source qui soutient le risque de schéma actif. La version installée actuelle est vérifiée, mais aucune plage de releases Next vulnérables n’est déduite de ce constat applicatif.

Exploitability Analysis

L'impact attendu est l'exécution d'un script dans le contexte du site après connexion, sous réserve du comportement réel du navigateur et du routage. Des requêtes authentifiées seraient alors possibles même si le script ne peut pas lire le cookie HttpOnly. Aucun vol effectif de données, contournement de mot de passe ou exploitation sans interaction de la victime n'est démontré. Gravité historique élevée en raison du contexte authentifié atteint.

Le code applicatif établit le chemin décrit, mais ne renseigne pas les protections effectives d'un déploiement donné, sa version en ligne ou les accès déjà exercés par un attaquant. La gravité ci-dessus est celle du mécanisme vulnérable avant correction ; elle n'est pas un score de risque résiduel calculé pour la production.

Proof of Concept

Tests de non-régression existants, inspectables dans le dépôt :

Ils testent les refus et les usages autorisés avec des données locales. Ils ne prouvent pas qu'une ancienne exploitation a eu lieu en production. Les commandes et résultats consolidés sont dans VALIDATION.md ; aucun nouvel exploit n'a été exécuté pendant la rédaction.

Remediation

Corrigé dans le code suivi de check_secu. safeLoginRedirect n'accepte que les chemins internes commençant par un seul slash et rejette antislashs et caractères de contrôle ; la validation est appliquée par le contexte actif. Déploiement inconnu.

Pour solder le constat en exploitation, vérifier le comportement sur la version effectivement déployée et conserver les contrôles légitimes décrits. La présente passe ajoute uniquement de la documentation ; les correctifs mentionnés existaient avant sa rédaction.

Summary

La redirection de connexion permet une XSS DOM est un constat historique de l'audit, à lire avec son état courant ci-dessus. La preuve porte sur le mécanisme et les contrôles cités ; elle ne constitue ni une attestation d'exploitation réelle ni une certification exhaustive du projet.

5.7 KiB Raw Blame History Unescape Escape