Securisation - loyde07/RDI25 GitHub Wiki

Résumé coaching 9

ANALYSE DE SECURITE
+ Le groupe a effectué et documenté sur le wiki une analyse de sécurité correcte, en identifiant les biens à protéger et en estimant les menaces et les risques associés.
+ Le groupe a identifié des contre-mesures adéquates pour l'ensemble des menaces identifiées.  
+ Le groupe connait et documente les limites de son travail de sécurisation (risques résiduels, …)
+ Le groupe a réfléchi au suivi des aspects sécurité du projet tout au long du cycle de vie du projet
+ Un diagramme de flux de données est attendu
	
SECURISATION	
+ Le groupe a mis en place les éléments de sécurité demandés dans le cadre du cours. Le groupe justifie et implémente correctement les mesures de sécurité au niveau du serveur (Utilisation https, version à jour / patchée, réflexion sur le hardening du serveur -par ex : pas d’autre port ouvert-, gestion des connexions et sessions, disponibilité, …), au niveau logiciel ( Librairies / Framework utilisés à jour, XSS, SQLi,gestion/stockage des mots de passe, ... ) et de la DB ( Inaccessible de l’extérieur, permissions / rôles définis adéquatement, backup, …)
	
VALIDATION DE LA SECURITE
+ Les étudiants ont utilisé des outils extérieurs pour valider la sécurisation de leur site, et présentent les résultats sur le wiki
+ Les étudiants ont compris, interprété et pris en compte les retours donnés par les outils extérieurs et corrigé les failles de sécurité éventuellement identifiées
	
ASPECTS LEGAUX	
+ Le wiki présente les contraintes légales auquel est soumis le site web (notamment RGPD)
+ Le wiki présente ce qui a été mis en place, ou aurait dû être mis en place, pour respecter le prescrit légal (traitement des données, backup, …)

1. Analyse de la sécurité

1.1 Biens à protéger

[Quels sont les éléments importants qu'il faut absolument sécuriser? Pourquoi? Réfléchissez chaque fois en termes de disponibilité/confidentialité/intégrité. Vous devriez au minimum aborder :

  • Le code,
  • la DB
  • et le serveur. ]
Élément Protection (C.I.D) Explications
Jetons d'authentification (JWT) Confidentialité, Intégrité Protégés via HttpOnly, Secure, et sameSite=strict. Clé secrète (JWT_SECRET) critique.
Mots de passe (DB) Confidentialité Chiffrés avec bcrypt. Suppression côté client (password: undefined).
Routes frontend Intégrité Vérification systématique via ProtectedRoute et RedirectAuthenticatedUser.
Variables d'environnement Confidentialité .env protégé (mais JWT_SECRET et credentials MongoDB exposés dans le code partagé).
Élément Protection (C.I.D) Explications
Rôles et permissions Confidentialité, Intégrité Accès restreint selon le rôle (admin, capitaine), empêche les modifications non autorisées.
Endpoints API sensibles Confidentialité Adresse IP et port backend masqués via variable d'environnement.

1.2 Risques

[Pour chaque élément, indiquez :

  • quelles menaces risquent de l'impacter,
  • avec quelle probabilité
  • et quel impact de l'attaque qui résulterait de cette menace.
    Classez ces menaces en fonction du risque.]
Élément Menace Probabilité Impact Risque
JWT Vol de token (XSS) Moyenne Critique Élevé
MongoDB Injection NoSQL (via API non validée) Élevée Critique Critique
Routes non protégées Accès non autorisé (ex: /dashboard) Faible Élevé Moyen
.env Fuite de secrets (GitHub) Moyenne Critique Élevé

|

1.3 Contre-mesures

[Pour chaque menace identifiée plus haut, quelle(s) contre-mesure(s) pourrait-on mettre en place? Indiquez si vous l'avez implémentée ou non, et si oui : comment? Décrivez brièvement les configurations mises en place.]

Menace Contre-mesure Implémenté ? Détails
Vol de JWT Cookies HttpOnly + Secure + sameSite=strict Oui Bloque les attaques XSS/CSRF.
Injection NoSQL Validation des entrées (manquante dans l'exemple) Non À ajouter avec express-validator.
Fuites de .env Fichier .env dans .gitignore Oui Mais clés partagées en clair dans le code (risque élevé).
Accès non autorisé ProtectedRoute + vérification isAuthenticated et isVerified Oui Redirection vers /login ou /verifyEmail.
Menace Contre-mesure Implémenté ? Détails
Accès illégitime aux fonctions réservées Vérification des rôles (isAdmin, isCaptain) avant action critique Oui Middleware côté backend qui bloque les actions sensibles (ex. suppression équipe) selon rôle utilisateur.
Scan d'API ou attaque directe sur IP/port VPS Utilisation de variable d'environnement pour cacher les endpoints sensibles Oui Les URLs des API ne sont pas exposées en dur dans le frontend.

  • Cookies sécurisés :
    Les JWT ne sont accessibles que via axios.defaults.withCredentials = true (cookie HttpOnly), ce qui bloque les attaques XSS classiques.

  • Gestion d'erreur :
    Les erreurs API sont capturées et affichées sans exposer de détails techniques (ex: error.response.data.message).

  • Protection des routes :
    Le store est utilisé par ProtectedRoute pour vérifier isAuthenticated et user.isVerified.

1.4 Suivi de la sécurisation

[Au quotidien, comment s'assurer que l'application n'est pas compromise? Où trouver des informations (logs, monitoring, ...) Qui s'occuperait potentiellement de la surveillance et de la maintenance? Quel est votre interprétation des résultats et quelles mesures ont alors été mises en place ?]

  • Monitoring :
    • Logs des connexions (lastLogin dans MongoDB).
    • Vérification des accès API via middleware de logs (morgan).

1.5 Diagramme de flux de données

2. Sécurisation

[Tout ce qui a été mis en place pour sécuriser l'application, le serveur, la DB, ... ]

Frontend :

  • Routes protégées (ProtectedRoute) et redirection des utilisateurs authentifiés (RedirectAuthenticatedUser).

Backend :

  • Cookies sécurisés :
    Les JWT ne sont accessibles que via axios.defaults.withCredentials = true (cookie HttpOnly), ce qui bloque les attaques XSS classiques.

  • Mots de passe chiffrés (bcrypt) et retirés des réponses API.

  • Gestion d'erreur :
    Les erreurs API sont capturées et affichées sans exposer de détails techniques (ex: error.response.data.message).

  • Gestion des permissions : Middleware personnalisé vérifie les rôles avant d’autoriser certaines actions (isAdmin, isCaptain, etc.), ce qui réduit les risques de manipulation de données par un utilisateur non autorisé.

  • Protection des routes API : Les URLs et ports du backend ne sont pas exposés en dur. Utilisation de variables d’environnement pour éviter toute fuite d’informations techniques sur l’infrastructure (ex. IP VPS).

3. Validation de la sécurité

[Avez-vous utilisé des outils de vérification de la sécurité de votre application? Ou avez-vous demandé ou effectué un "pentest" de votre application, par ex. avec un autre groupe? ]

  • Tests manuels :
    • Tentative d'accès à /dashboard sans token → redirection vers /login.
    • Test de fuite de JWT via XSS (bloqué par HttpOnly).
  • Outils :
    • npm audit : vérification des vulnérabilités des dépendances.
    • À faire : Test OWASP ZAP pour injections/XSS.

4. Cadre légal

4.1 Contraintes légales

[Présentation des contraintes légales s'appliquant à votre application]

  • Données utilisateurs :
    • Chiffrement des mots de passe (bcrypt).
    • Droit à l'oubli non implémenté (nécessite une route DELETE /user).

4.2 Mise en oeuvre de ces contraintes

[Explication de ce qui a été mis en place pour respecter le cadre légal dans le cadre de ce projet]

  • Consentement : Politique de confidentialité absente (à ajouter).
  • Minimisation des données : Suppression du password côté client.

5. Bilan et Limites

[D'après vous, est-ce que la sécurisation mise en place est suffisante? Pourquoi? Quelles sont les limites ? Et les améliorations à envisager ?]

Points forts :

  • Authentification : JWT sécurisés et routes protégées.
  • Confidentialité : Mots de passe chiffrés et cachés côté client.
  • Contrôle d'accès basé sur les rôles : implémentation d'une logique fine pour restreindre certaines actions (modification de données, accès admin) selon les rôles des utilisateurs (admin, capitaine).

Limites critiques :

  1. Secrets en clair :
    • MONGO_URI et JWT_SECRET exposés (solution : on pourrait utiliser AWS Secrets Manager ou équivalent).
  2. Validation des entrées :
    • Absence de sanitization des requêtes API (risque d'injection NoSQL).

**Améliorations à venir suggéré par chatGpt ** :

  • Backend :
    • Ajouter express-validator pour valider req.body.email/req.body.password.
    • Mettre en place une rotation des clés JWT.
  • DevOps :
    • Chiffrer les variables sensibles avec Docker Secrets ou Kubernetes Vault.
  • Audit des rôles : ajouter des logs pour tracer qui a effectué quelles actions (utile pour post-mortem en cas de faille ou erreur humaine).