Securisation - ZosiscoIV/Dev-Web-2024 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é

Site : https://epicerie-didier.linadu.live/

1.1 Biens à protéger

Dans le code :

  • Les données sensibles (ex : noms d'utilisateur, mots de passe, informations de connexion à la base de données).
  • Les entrées utilisateur doivent être validées afin d'éviter les injections malveillantes.
  • les cookies notamment ceux liés à l’authentification, doivent être protégés contre le vol et les accès non autorisés (via HttpOnly, Secure, SameSite, etc.).

Dans la base de données :

  • Les comptes à haut privilèges (ex : root).
  • Les données de payement
  • Les données des clients (mdp, identifiants, etc.).

Sur le serveur :

  • Tokens d’authentification : doivent être stockés de manière sécurisée et invalidés régulièrement.
  • Données confidentielles : ne doivent jamais transiter en clair (protection via HTTPS).
  • Points d’entrée du serveur : à sécuriser (firewall, ports fermés, services inutiles désactivés).
  • Certificats SSL et clés privées : à stocker en local avec des permissions restreintes.
  • Fichiers de configuration : .env, config.js, etc., doivent être exclus du dépôt et bien protégés.
  • Logs : doivent être sécurisés et surveillés, sans stocker d'informations critiques (ex : mots de passe).

1.2 Risques

Code :

Variables d'environnement :

  • Menace : exposition accidentelle des variables sensibles.
  • Probabilité : élevée.
  • Impact : très élevé (accès à la base de données).
  • Risque : élevé.

Entrées utilisateur :

  • Menace : XSS (Cross-site Scripting).
  • Probabilité : moyenne.
  • Impact : élevé (vol de données utilisateur).
  • Risque : élevé.

Cookies :

  • Menace : vol ou manipulation de cookies.
  • Probabilité : moyenne.
  • Impact : élevé (vol d’identité, usurpation de session).
  • Risque : élevé.

Base de données :

données de paiement

  • Menace : interception ou vol de données bancaires.
  • Probabilité : moyenne.
  • Impact : Très élevé (responsabilité légale, perte de confiance).
  • Risque : élevé.

Accès non autorisé

  • Menace : compromission d’un compte avec privilèges élevés (ex. root).
  • Probabilité : moyenne.
  • Impact : très élevé (vol ou suppression de données).
  • Risque : élevé.

Serveur :

HTTP non sécurisé

  • Menace : transmission de données sensibles sans chiffrement.
  • Probabilité : élevée.
  • Impact : élevé (usurpation d'identité, vol de données).
  • Risque : élevé.

Ports ouverts / services inutiles

  • Menace : attaques par force brute, scans de ports, exploitation de services exposés.
  • Probabilité : moyenne.
  • Impact : élevé.
  • Risque : élevé.

Fichiers de configuration exposés

  • Menace : accès à des fichiers .env, config.js, etc.
  • Probabilité : moyenne.
  • Impact : très élevé (exposition d’identifiants, mots de passe).
  • Risque : élevé.

Logs non protégés

  • Menace : fuite d’informations sensibles via les fichiers de log.
  • Probabilité : moyenne.
  • Impact : élevé
  • Risque : élevé.

Classement des risques :

  • S Tier : Injections SQL
  • A Tier : XSS, fuite de variables, HTTP non sécurisé
  • B Tier : Vol de cookies, ports ouverts

1.3 Contre-mesures

Variables d'environnement

  • Contre-mesure : Utilisation d’un fichier .env pour stocker les informations sensibles
  • Implémenté : ✅
  • Configuration : Fichier .env + ajout au .gitignore. Et les données sensibles sont accédées via process.env.

Injections SQL

  • Contre-mesure : Requêtes paramétrées.
  • Implémenté : ✅

XSS (Cross-site scripting)

  • Contre-mesure : Nettoyage systématique des entrées utilisateur avec par exemple DOMPurify.
  • Implémenté : Partiellement ✅

HTTP / Transimission de données

  • Contre-mesure : Utilisation systématique du HTTPS via un certificat SSL valide (Let's Encrypt). Avec la redirection automatique HTTP => HTTPS
  • Implémenté : ✅

Cookies & sessions ✅

  • Contre-mesure : Cookies marqués HttpOnly + Secure + SameSite=strict. + Stockage uniquement des tokens nécessaires, avec durée de vie limitée.
  • Implémenté : NON
  • configuration

Authentification

  • Contre-mesure : Authentification via JWT (JSON Web Tokens).
  • Implémenté : ✅
  • Configuration :

Configuration serveur

  • Contre-mesure : Ports inutiles fermés + Firewall iptable + fail2Ban
  • Implémenté : ✅
  • Configuration : tout ce qu'on à fait au TP03

Logs & fichiers sensibles

  • Contre-mesure : Aucun mot de passe ni token stocké dans les logs.
  • Implémenté : ✅
  • Configuration :

Validation des données du produit

  • Contre-mesure : Double validation des données :
    • Frontend : utilisation de React Hook Form pour la gestion et validation des formulaires (ex : champ "min=0", "required") pour empêcher des valeurs invalides ou vides.
    • Backend : utilisation d’un validateur spécifique (Product Validator) pour s’assurer que les données reçues respectent les contraintes attendues, même si une tentative de contournement du frontend était faite.
  • Implémenté : ✅

Gestion des droits d'accès

  • Contre-mesure : Mise en place d'un contrôle des rôles. Seul un utilisateur avec le rôle "admin" peut accéder à l'inventaire, créer un produit, modifier un produit ou rendre un produit indisponible.
  • Implémenté : ✅
  • Configuration : Vérification du rôle de l'utilisateur (JWT + vérification côté backend) avant autorisation des routes protégées.

1.4 Suivi de la sécurisation

  • Mises à jour régulières des composants (Nginx, Linux, MySQL...)
  • Surveillance des logs système et applicatifs.
  • Monitoring des ressources serveur.
  • Scan de vulnérabilités périodique.
  • Backups réguliers et testés.

1.5 Diagramme de flux de données

(à intégrer graphiquement ici ou sur le Wiki)

yg2rq1sa

2. Sécurisation mise en place

Code :

  • Fichier .env pour stocker les variables sensibles (et mis dans .gitignore) ✅
  • DOMPurify pour contrer les XSS ✅
  • Utilisation de requêtes paramétrées pour prévenir les injections SQL ✅
  • Cookies protégés avec les flags HttpOnly, Secure, SameSite ✅
  • Double validation des formulaires dans l'inventaire : React Hook Form côté frontend + Product Validator côté backend ✅
  • Contrôle d'accès basé sur les rôles : Seuls les administrateurs peuvent modifier, créer ou rendre des produits indisponibles ✅

Base de données :

  • Utilisateur DB avec droits limités (pas de root) ✅
  • Requêtes paramétrées ✅
  • Pas d'accès à la DB depuis l'extérieur ✅
  • Mots de passe hashés ✅ (Thomas)

Serveur :

  • HTTPS activé ✅ (Théo)
  • Authentification via JWT ✅ (Thomas)
  • Content-Security-Policy ✅ (Théo)

3. Validation de la sécurité

  • Outil utilisé :
  • OWASP ZAP pour effectuer des scans de sécurité.
  • CSP Evaluator
  • Possibilité d'un test par un camarade (Robin).

4. Cadre légal

4.1 Contraintes légales

L'application doit être conforme au RGPD (Règlement Général sur la Protection des Données), car nous collectons des informations personnelles (noms, prénoms, etc.).

En cas de faille de sécurité grave, la responsabilité légale peut être engagée si des protections suffisantes n'ont pas été mises en place.

4.2 Mise en oeuvre des contraintes

  • Pas de cookies de tracking (type Google Analytics).
  • Ajout prévu d'une page "Politique de confidentialité".
  • Protection des données : pas de stockage en clair, base de données isolée, accès limités.

5. Bilan et limites

Points positifs :

  • La base est solide (JWT, HTTPS, DB protégée, fichiers sensibles isolés).
  • Les attaques les plus courantes sont traitées (XSS, SQLi).
  • Contrôle d'accès en place pour protéger les routes sensibles liées à l'inventaire.
  • Double vérification des données du produit pour renforcer la sécurité des entrées.

Limites actuelles :

  • Certaines fonctionnalités sont encore en cours (authentification, nettoyage systématique).
  • Pas encore de tests de sécurité automatisés.
  • Surveillance continue à améliorer.

Améliorations possibles :

  • Intégration de tests de sécurité dans le CI/CD.
  • Mise en place de monitoring temps réel (Sentry, LogRocket...)
  • Analyse automatique régulière (Snyk, Dependabot...).