Skip to main content
Les vulnérabilités de gestion des sessions permettent aux attaquants de voler ou falsifier des jetons de session, détournant les sessions utilisateur authentifiées sans connaître le mot de passe.

​
session-id-in-url

Critique Description Les identifiants de session apparaissent dans l’URL sous forme de paramètres de requête (ex. : ?sessionid=abc123, ;jsessionid=xyz), les rendant visibles dans l’historique du navigateur, les journaux du serveur, les en-têtes de référent et les liens partagés. Importance Une URL contenant un ID de session peut être :
  • Divulguée via l’en-tête HTTP Referer vers des sites tiers
  • Stockée dans l’historique du navigateur et accessible aux autres utilisateurs de la même machine
  • Capturée dans les journaux d’accès du serveur
  • Accidentellement partagée dans une capture d’écran ou un lien copié-collé
Chacun de ces scénarios résulte en un détournement de session sans attaque active. Comment QAOS le détecte L’agent inspecte l’URL actuelle après chaque navigation pour détecter des paramètres ressemblant à des identifiants de session : sessionid, session, sid, token, jsessionid, PHPSESSID et motifs similaires. Exemples 
https://app.example.com/dashboard?sessionid=abc123def456
https://app.example.com/page;jsessionid=ABCDEFG1234567
https://app.example.com/home?sid=user_9876token
Comment corriger Stockez les identifiants de session exclusivement dans des cookies avec les flags HttpOnly et Secure définis. Ne transmettez jamais les jetons de session via des URLs. Si vous héritez d’un système legacy utilisant des sessions basées sur l’URL, migrez vers des sessions basées sur les cookies et implémentez SameSite=Strict ou SameSite=Lax.

​
session-id-in-hidden-field

Élevé Description Les identifiants de session sont intégrés dans des champs de formulaire cachés ou des éléments DOM accessibles côté client (ex. : <input type="hidden" name="session_id">), les rendant lisibles par tout JavaScript sur la page. Importance Les champs de formulaire cachés font partie du DOM et sont accessibles via JavaScript comme tout autre élément. Une vulnérabilité XSS n’importe où sur la page peut extraire l’ID de session d’un champ caché et l’exfiltrer vers un serveur contrôlé par un attaquant. Comment QAOS le détecte L’agent analyse le DOM pour les champs de saisie cachés et les métadonnées côté client dont les noms ou valeurs correspondent à des motifs d’identifiants de session (session_id, token, auth, sid, etc.). Exemples 
<!-- ID de session dans un champ caché — lisible par tout JS sur la page -->
<form action="/submit" method="POST">
  <input type="hidden" name="session_id" value="abc123def456">
</form>
Comment corriger N’intégrez jamais les identifiants de session dans le DOM. Stockez l’état de session côté serveur et référencez-le exclusivement via des cookies HttpOnly que JavaScript ne peut pas lire. Si vous devez transmettre un jeton CSRF via un champ de formulaire, utilisez un jeton CSRF séparé et à usage limité plutôt que l’ID de session lui-même.

​
session-id-reused-after-authentication

Élevé Description L’identifiant de session n’est pas renouvelé lorsqu’un utilisateur se connecte — le même ID de session qui existait avant l’authentification est utilisé pour la session authentifiée. Cela crée une vulnérabilité de fixation de session. Importance Dans une attaque de fixation de session, un attaquant plante un ID de session connu dans le navigateur de la victime (ex. : via un lien malveillant ou XSS). Si l’application réutilise cet ID de session après la connexion, l’ID connu de l’attaquant devient authentifié et il obtient accès au compte de la victime. Comment QAOS le détecte L’agent capture la valeur du cookie de session avant la connexion, complète le flux d’authentification, puis compare la valeur du cookie de session après. Si la valeur est inchangée, la fixation de session est possible. Comment corriger Émettez un nouvel ID de session immédiatement après une authentification réussie : 
# FastAPI / Starlette — invalider l'ancienne session, en créer une nouvelle
request.session.clear()
request.session["user_id"] = user.id
# Le framework émet automatiquement un nouveau cookie de session

# Express.js avec express-session
req.session.regenerate((err) => {
  req.session.userId = user.id
})

​
missing-session-invalidation

Élevé Description La déconnexion n’invalide pas la session côté serveur. Le cookie de session reste valide après la déconnexion, permettant à un utilisateur (ou à un attaquant qui a capturé le cookie) de continuer à utiliser la session authentifiée. Importance Si un utilisateur se déconnecte sur un ordinateur partagé, ou si son cookie de session a été préalablement volé, l’attaquant conserve l’accès indéfiniment. L’invalidation correcte de session est le seul moyen de garantir qu’une déconnexion met réellement fin à la session. Comment QAOS le détecte L’agent capture le cookie de session, effectue une déconnexion, puis tente d’accéder aux pages authentifiées en utilisant le cookie capturé. Si l’accès est toujours accordé, l’invalidation de session est manquante. Comment corriger Invalidez la session côté serveur lors de la déconnexion — supprimez l’enregistrement de session du magasin, pas seulement le cookie côté client : 
# FastAPI / Starlette
request.session.clear()  # supprime les données de session côté serveur

# Express.js
req.session.destroy((err) => {
  res.clearCookie('connect.sid')
  res.redirect('/login')
})
Effacer le cookie côté client n’est pas suffisant — le serveur doit rejeter l’ID de session même si le client l’envoie.