Cookie de session compromis

Si un cookie de session est compromis, une durée de session plus longue donne effectivement à l'attaquant plus de temps pour exploiter la session active. Voici pourquoi cela se produit et comment y remédier :

• Session Hijacking (Détournement de session) : Si un attaquant parvient à intercepter ou voler le cookie de session (par exemple, via une attaque Man-in-the-Middle, un XSS ou une fuite côté client), il peut utiliser ce cookie pour se faire passer pour l'utilisateur légitime. Une session active plus longue signifie que l'attaquant peut accéder aux ressources de l'utilisateur sans avoir à se ré-authentifier.
• Durée de vie prolongée : Si la session est configurée pour durer plusieurs heures ou même jours, cela augmente la fenêtre d'exploitation. Une session courte limite le temps disponible pour que l'attaquant utilise le cookie compromis.
• Absence de validation continue : Une session trop longue combinée à l'absence de vérification côté serveur (comme une validation du contexte de l'utilisateur, IP ou appareil) peut rendre l'attaque plus facile.

Mesures de protection contre l'exploitation des cookies de session en ASP.NET

• Limiter la durée de la session : Réduisez la durée des sessions pour minimiser le temps d'utilisation d'un cookie volé :
<configuration>
  <system.web>
     <sessionState timeout="20" />
  </system.web>
</configuration>


• Marquer les cookies comme sécurisés : Activez les attributs HttpOnly et Secure pour protéger les cookies :
• HttpOnly : Empêche l'accès aux cookies via JavaScript, ce qui réduit les risques liés aux attaques XSS.
• Secure : Assure que le cookie est transmis uniquement via des connexions chiffrées (HTTPS).

Exemple dans le fichier web.config :

<system.web>    <httpCookies httpOnlyCookies="true" requireSSL="true" /> </system.web>



• Activer SameSite pour les cookies : Configurez l'attribut SameSite pour empêcher que les cookies soient envoyés lors de requêtes cross-site, ce qui bloque les attaques CSRF :
1. <system.web>
2.   <httpCookies sameSite="Strict" />
3. </system.web>


• Régénérer les cookies après une authentification sensible : Par exemple, régénérez l'ID de session après une connexion réussie :
1. Session.Abandon();
2. SessionIDManager manager = new SessionIDManager();
3. manager.RemoveSessionID(HttpContext.Current);
4. manager.CreateSessionID(HttpContext.Current);


• Activer la protection contre le vol de session : Liez la session à l'IP ou au User-Agent de l'utilisateur pour détecter les anomalies :
1. var userIp = HttpContext.Current.Request.UserHostAddress;
2. var userAgent = HttpContext.Current.Request.UserAgent;
3.  
4. if (Session["UserIp"] == null) {
5.      Session["UserIp"] = userIp;
6.      Session["UserAgent"] = userAgent;
7. } else if (Session["UserIp"].ToString() != userIp || Session["UserAgent"].ToString() != userAgent) {
8.      Session.Abandon(); // Déconnecter l'utilisateur
9. }


• Utiliser des jetons CSRF : Implémentez des jetons anti-CSRF pour protéger les requêtes sensibles, même si un cookie est compromis.
• Suivre les anomalies : Implémentez une journalisation des connexions avec les cookies pour détecter des connexions suspectes provenant d'autres emplacements.

Mesures de protection contre l'exploitation des cookies de session en Fano Framework

Voici les principales mesures de protection contre l'exploitation des cookies de session et les mécanismes que vous pouvez mettre en place manuellement dans le contexte Fano Framework en Free Pascal :

• Activation de l'attribut HttpOnly : L'attribut HttpOnly empêche les cookies de session d'être accessibles via JavaScript, réduisant les risques d'attaques XSS (Cross-Site Scripting). Dans le Fano Framework, vous pouvez configurer cet attribut lorsque vous définissez un cookie de session :
1. response.setCookie('SESSION_ID', sessionId, [
2.     'HttpOnly'
3. ]);


• Transmission sécurisée (HTTPS uniquement) : Pour empêcher qu'un cookie soit transmis en clair sur des connexions non sécurisées, l'attribut Secure doit être activé. Cela garantit que le cookie est transmis uniquement via HTTPS. Exemple dans le Fano Framework :
  1. response.setCookie('SESSION_ID', sessionId, [
  2.     'Secure',
  3.     'HttpOnly'
  4. ]);

  Assurez-vous que votre serveur Web (comme Nginx ou Apache) est configuré pour forcer l'utilisation de HTTPS.

• Limitation des requêtes intersites (SameSite) : L'attribut SameSite protège les cookies contre les attaques CSRF (Cross-Site Request Forgery) en empêchant leur inclusion dans des requêtes provenant d'autres sites. Configuration dans le Fano Framework :
1. response.setCookie('SESSION_ID', sessionId, [
2.     'SameSite=Strict'
3. ]);

Les options possibles pour SameSite sont :

Option	Description
Strict	Bloque complètement l'accès aux cookies pour des requêtes cross-site.
Lax	Permet les cookies pour certaines requêtes sécurisées (comme les requêtes GET depuis un lien).
None	Permet les cookies pour toutes les requêtes cross-site (peu sécurisé).



• Rotation des cookies de session : Pour minimiser l'impact d'un cookie de session volé, il est recommandé de régénérer l'identifiant de session après des actions sensibles (comme une authentification ou une élévation de privilèges). Implémentation dans le Fano Framework :
• Détruisez la session existante.
• Créez un nouveau cookie avec un nouvel identifiant.
1. sessionManager.destroySession(sessionId);
2. newSessionId := sessionManager.createNewSession();
3. response.setCookie('SESSION_ID', newSessionId, [
4.     'HttpOnly',
5.     'Secure'
6. ]);


• Réduction de la durée de vie des sessions : Fixer une durée de vie raisonnable pour les cookies limite le temps disponible pour qu'un attaquant exploite un cookie volé. Exemple dans le Fano Framework (expiration après 30 minutes) :
1. response.setCookie('SESSION_ID', sessionId, [
2.     'HttpOnly',
3.     'Secure',
4.     'Max-Age=1800' // 1800 secondes = 30 minutes
5. ]);


• Validation des sessions côté serveur : Les sessions doivent être validées côté serveur pour éviter les détournements de session. Utilisez un gestionnaire de sessions (par exemple, un stockage Redis ou une base de données) pour vérifier si le cookie de session correspond à une session valide. Implémentation simplifiée dans le Fano Framework :
1. If Not sessionManager.isValidSession(sessionId)Then Begin
2.  Response.StatusCode := 403; (* Accès interdit *)
3.  Response.Body().Write('Invalid session');
4. End;


• Limitation de l'accès aux cookies aux domaines et chemins spécifiques : Réduisez l'accès aux cookies uniquement au domaine et au chemin nécessaires. Exemple de configuration de cookie pour un chemin spécifique :
  1. response.setCookie('SESSION_ID', sessionId, [
  2.     'Path=/secure/',
  3.     'HttpOnly',
  4.     'Secure'
  5. ]);
  
  
• Jetons anti-CSRF : Même avec l'attribut SameSite, il est recommandé d'utiliser des jetons anti-CSRF pour valider les requêtes sensibles. Bien que le Fano Framework n'implémente pas directement un système de jetons anti-CSRF, vous pouvez en ajouter manuellement :
  • Générer un jeton unique pour chaque session.
  • Inclure ce jeton dans les formulaires ou les requêtes via des champs cachés.
  • Vérifier le jeton côté serveur avant d'exécuter une requête.
• Journalisation des activités suspectes : Configurez la journalisation pour détecter des comportements inhabituels liés aux sessions, comme plusieurs connexions avec le même identifiant depuis des adresses IP différentes.

Résumé des mesures dans le Fano Framework pour Free Pascal :