> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qaos.machdel.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Gestion des sessions
> Critères liés à la création, au stockage et à la transmission des sessions — incluant l'exposition des jetons, la faible entropie et les flags de sécurité manquants sur les cookies.
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. : ``), 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**
```html theme={null}
```
**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 :
```python theme={null}
# 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 :
```python theme={null}
# 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.