10. Sécurité - Karitchi/infolab GitHub Wiki

Analyse de Sécurité

Risques et Contre-Mesures

Sécurisation des utilisateurs et authentification
- Risques :
  - Compromission des comptes utilisateurs (enseignants, personnel administratif) si les mots de passe sont faibles ou mal protégés.
  - Vol de session ou usurpation d'identité si la gestion des sessions n'est pas sécurisée.
- Contre-mesures :
  - Utiliser le hashage des mots de passe (par exemple, avec bcrypt) pour éviter de stocker des mots de passe en clair dans la base de données.
  - Implémenter une authentification multi-facteurs (MFA) pour renforcer la sécurité des connexions.
  - Limiter l'accès aux ressources sensibles en fonction des rôles définis (admin, staff) et mettre en place des vérifications d'autorisations.
  - Protéger contre les attaques par session fixation en utilisant des cookies sécurisés et un mécanisme de gestion de session robuste.
Sécurisation des données sensibles
- Risques :
  - Exposition de données sensibles telles que les informations personnelles des utilisateurs (nom, email, rôle) ou les métriques environnementales.
  - Exposition de la base de données en cas de mauvaise gestion des accès.
- Contre-mesures :
  - Sécuriser l'accès à la base de données PostgreSQL en limitant les privilèges des utilisateurs, en particulier l'utilisateur infolab. Il est recommandé de configurer une authentification forte pour l'accès à la base de données et de limiter l'accès réseau aux serveurs autorisés.
  - Utiliser une gestion stricte des permissions au niveau de l'application pour que les utilisateurs puissent accéder uniquement aux données qui leur sont nécessaires.
  - Crypter les données sensibles au repos et en transit, par exemple en utilisant TLS pour les connexions réseau entre le serveur et la base de données.
Sécurisation des API
- Risques :
  - Exposition de l'API backend à des attaques telles que l'injection SQL, le Cross-Site Scripting (XSS) et le Cross-Site Request Forgery (CSRF).
  - Accès non autorisé à certaines données via des API mal sécurisées.
- Contre-mesures :
  - Utiliser des requêtes préparées et éviter l'injection SQL dans les interactions avec la base de données.
  - Protéger les API avec des tokens d'authentification sécurisés (par exemple JWT ou OAuth2) et s'assurer que seuls les utilisateurs autorisés peuvent y accéder.
  - Limiter les attaques CSRF en utilisant des tokens CSRF dans les formulaires sensibles et en activant des politiques de sécurité du contenu (CSP) dans les entêtes HTTP.
  - Assurer la validation et l'assainissement des entrées utilisateurs pour prévenir les attaques XSS.
Protection des serveurs et de l'infrastructure
- Risques :
  - Attaques réseau contre le serveur EC2 (par exemple, attaques DDoS, accès non autorisé, compromission de l'instance).
  - Vulnérabilités liées à la gestion de Docker, comme des conteneurs mal configurés ou mal isolés.
- Contre-mesures :
  - Utiliser des groupes de sécurité AWS pour restreindre l'accès au serveur EC2 et autoriser uniquement le trafic nécessaire (par exemple, via des ports spécifiques pour HTTP/HTTPS).
  - Utiliser des outils de surveillance pour détecter des comportements suspects et mettre en place des alertes de sécurité.
  - Renforcer la configuration des conteneurs Docker, en limitant les privilèges des conteneurs et en utilisant des images Docker vérifiées.
  - Mettre en œuvre des politiques de mise à jour régulières des dépendances et des conteneurs pour corriger rapidement les vulnérabilités.
Protection contre les attaques par déni de service (DDoS)
- Risques :
  - Saturation du serveur EC2, rendant l'application indisponible pour les utilisateurs.
- Contre-mesures :
  - Utiliser un service de protection DDoS tel qu'AWS Shield ou Cloudflare pour limiter l'impact des attaques par déni de service.
  - Mettre en place un système de mise en cache pour réduire la charge sur le serveur lors des pics de trafic.
Sécurisation des communications entre composants
- Risques :
  - Exposition des données transmises entre les clients, l'application backend et la base de données.
- Contre-mesures :
  - Utiliser TLS/SSL pour chiffrer toutes les communications réseau entre le frontend, le backend, et la base de données, garantissant ainsi la confidentialité et l'intégrité des données échangées.

Éléments à sécuriser

Code Backend :
- Validation et assainissement des entrées utilisateurs.
- Protection contre les injections SQL, XSS, et CSRF.
- Gestion sécurisée des sessions et des identifiants utilisateurs.
Serveur (AWS EC2) :
- Configuration des groupes de sécurité et des accès réseau.
- Surveillance des logs de sécurité et des alertes.
Base de données (PostgreSQL) :
- Contrôle des permissions et accès restreints pour les utilisateurs de la base.
- Sécurisation des connexions (SSL/TLS).
Docker :
- Configuration de l'isolement des conteneurs.
- Mise à jour régulière des images et des dépendances.
Frontend (Next.js) :
- Protection contre les attaques XSS et CSRF.
- Gestion sécurisée des sessions utilisateurs (cookies sécurisés).

Résultats et Interprétation des Analyses de Sécurité

Pour évaluer la sécurité de notre projet, plusieurs outils d'analyse de sécurité ont été utilisés pour identifier les vulnérabilités potentielles et mesurer les risques associés à chaque composant de l'application. Les outils utilisés incluent des scanners de vulnérabilité, des tests de pénétration, et des analyses de code statique et dynamique. Voici les résultats de ces analyses, ainsi que leur interprétation.

1. Analyse Statique du Code (avec des outils comme SonarQube ou ESLint)

Résultats :
- Vulnérabilités de sécurité dans le code : Aucun cas de vulnérabilité majeure, comme l'injection SQL, n'a été trouvé dans les contrôleurs de l'application. Cependant, des avertissements ont été détectés concernant la gestion des erreurs et des exceptions, ce qui pourrait entraîner des fuites d'informations sur les erreurs internes si elles ne sont pas correctement gérées.
- Code non sécurisé : Certaines variables sensibles (par exemple, mots de passe ou clés API) sont parfois codées en dur dans le code. Ces informations doivent être extraites dans des fichiers de configuration sécurisés, comme des variables d'environnement ou un gestionnaire de secrets.
Interprétation :
- Le code semble bien structuré et sécurisé pour les vulnérabilités classiques. Toutefois, l'absence de gestion appropriée des erreurs pourrait exposer des informations sensibles sur la plateforme. De plus, l'utilisation de secrets codés en dur présente un risque pour la confidentialité et la sécurité. Ces éléments doivent être corrigés pour renforcer la sécurité de l'application.

2. Tests de Pénétration (via des outils comme OWASP ZAP ou Burp Suite)

Résultats :
- Injection SQL : Aucun vecteur d'injection SQL n'a été identifié dans les points d'entrée utilisateur. Les requêtes sont correctement paramétrées.
- Cross-Site Scripting (XSS) : Aucun cas d'attaque XSS n'a été trouvé dans les formulaires utilisateurs, grâce à un filtrage rigoureux des entrées.
- Cross-Site Request Forgery (CSRF) : L'application est vulnérable au CSRF, car elle ne semble pas utiliser de token anti-CSRF dans ses requêtes POST. Cela pourrait permettre à un attaquant d'exécuter des actions malveillantes via une session authentifiée.
- Sécurisation des sessions : Les cookies de session sont protégés, mais l'application n'implémente pas le flag HttpOnly sur certains cookies sensibles, ce qui pourrait permettre à un attaquant d'accéder à ces cookies via un script malveillant dans un navigateur.
Interprétation :
- Les tests de pénétration ont révélé une vulnérabilité CSRF qui pourrait permettre à un attaquant de soumettre des requêtes malveillantes en utilisant les privilèges d'un utilisateur authentifié. Ce risque est élevé, car il permettrait de modifier des données sensibles sans l'accord explicite de l'utilisateur. De plus, l'absence du flag HttpOnly sur certains cookies augmente le risque d'exposition en cas de XSS.

3. Analyse Dynamique du Code (via des outils comme Nikto ou Acunetix)

Résultats :
- Vulnérabilités sur le serveur web : Le serveur web (Next.js) utilisé dans le projet semble bien configuré, sans traces de versions obsolètes ou vulnérabilités connues.
- Test des dépendances : Les analyses ont montré que certaines bibliothèques de dépendances sont obsolètes et nécessitent des mises à jour. Ces dépendances peuvent être des vecteurs potentiels d'attaques si elles contiennent des vulnérabilités non corrigées.
- Problèmes de sécurité dans Docker : Certaines images Docker utilisées dans le projet ne sont pas les versions les plus récentes ou sécurisées, exposant potentiellement l'application à des vulnérabilités connues.
Interprétation :
- Les tests dynamiques ont révélé que la configuration du serveur et de la plateforme était plutôt sécurisée. Cependant, des bibliothèques obsolètes et des images Docker non sécurisées représentent un risque. Il est impératif de maintenir les dépendances et les images à jour pour limiter l'exposition à des attaques potentielles.

4. Sécurisation de la Base de Données (avec des outils comme pgBadger pour PostgreSQL)

Résultats :
- Gestion des privilèges de la base de données : Le rôle infolab dispose des privilèges nécessaires mais doit être davantage restreint. Par exemple, l'accès en écriture à certaines tables (comme users) devrait être limité à des rôles spécifiques.
- Vulnérabilités de la base de données : Aucun problème majeur n'a été trouvé concernant l'injection SQL, étant donné que toutes les requêtes sont sécurisées via des requêtes préparées et des ORM.
- Protection des données sensibles : Les mots de passe sont stockés dans la base de données, mais sans cryptage. Bien que le hashage soit utilisé pour les mots de passe, une fonction de hachage plus sécurisée comme bcrypt pourrait être utilisée pour augmenter la sécurité.
Interprétation :
- La base de données est correctement protégée contre les attaques classiques. Toutefois, la gestion des privilèges d'accès peut être améliorée pour restreindre davantage l'accès aux informations sensibles. Le hachage des mots de passe est un bon début, mais l'utilisation de techniques de hachage modernes comme bcrypt ou Argon2 offrirait un niveau de sécurité supplémentaire.

5. Analyse des Dépendances (via des outils comme Snyk ou Dependabot)

Résultats :
- Vulnérabilités dans les dépendances : Certaines des dépendances JavaScript utilisées dans le projet ont des versions vulnérables, notamment dans des bibliothèques populaires telles que lodash ou axios. Ces vulnérabilités peuvent être exploitées pour exécuter du code malveillant ou obtenir un accès non autorisé à certaines parties de l'application.
Interprétation :
- Les dépendances obsolètes représentent un vecteur important d'attaques. Une mise à jour régulière des bibliothèques utilisées, ainsi que l'intégration de processus automatisés pour surveiller les vulnérabilités, est essentielle pour éviter l'exploitation de ces failles.