Securisation - dudleydehenau/ScapeGame 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

  • le déploiment
  • la DB
  • le backend
  • les API

1.2 Risques

Le système actuel présente plusieurs lacunes en matière de suivi de la sécurité, exposant l'infrastructure à divers risques.

  1. Absence de suivi régulier des vulnérabilités :

    • Menaces : Le système peut être affecté par des vulnérabilités non détectées, telles que des failles dans les bibliothèques tierces ou des exploits récemment découverts.
    • Probabilité : Élevée, car de nouvelles vulnérabilités sont fréquemment découvertes.
    • Impact : Une attaque réussie exploitant une vulnérabilité non détectée pourrait conduire à une compromission totale du système, y compris des violations de données sensibles et des interruptions de service.

  2. Manque de surveillance continue des activités suspectes :

    • Menaces : Les attaquants peuvent mener des activités malveillantes non détectées, telles que des tentatives d'intrusion, des exfiltrations de données ou des attaques par force brute.
    • Probabilité : Moyenne à élevée, en fonction de la nature et de la taille de la cible.
    • Impact : Une activité malveillante non détectée peut entraîner des pertes de données, une perte de confiance des utilisateurs, et des coûts supplémentaires pour la remédiation post-incident.

  3. Insuffisance des audits de sécurité périodiques :

    • Menaces : Les faiblesses de sécurité non découvertes, telles que des configurations mal sécurisées ou des permissions excessives, peuvent être exploitées par des attaquants.
    • Probabilité : Moyenne, car sans audits réguliers, il est difficile de détecter et de corriger les problèmes de sécurité.
    • Impact : Les failles non corrigées peuvent permettre des accès non autorisés, des modifications non désirées ou une exposition de données critiques, avec des conséquences potentielles majeures pour l'organisation.

  4. Absence de processus de mise à jour des dépendances :

    • Menaces : Utilisation de bibliothèques obsolètes avec des vulnérabilités connues, susceptibles d'être exploitées par des attaquants.
    • Probabilité : Élevée, étant donné la fréquence des mises à jour de sécurité pour les logiciels tiers.
    • Impact : L'exploitation des vulnérabilités dans les dépendances peut entraîner des accès non autorisés, une altération des données, et compromettre l'intégrité de l'ensemble du système.

1.3 Contre-mesures

  1. Clé JWT statique :

    • Utiliser une clé secrète robuste : Générer une clé complexe et difficile à deviner.
    • Stocker la clé de manière sécurisée : Utiliser des solutions comme les coffres-forts numériques ou les gestionnaires de secrets pour stocker la clé.
    • Régénération périodique de la clé : Changer la clé régulièrement pour limiter les impacts en cas de fuite.

  2. Validation des entrées :

    • Renforcer les règles de validation : Utiliser express-validator pour inclure des règles plus strictes, telles que des limites sur la longueur des entrées et des types de données acceptables.
    • Implémenter des filtres de caractères : Rejeter les caractères spéciaux ou dangereux qui pourraient être utilisés pour des attaques d'injection.
    • Utiliser des listes blanches : Restreindre les entrées aux valeurs attendues, en utilisant des listes blanches pour les champs qui doivent contenir des valeurs spécifiques.

  3. Gestion des erreurs :

    • Masquer les détails des erreurs : Ne pas afficher les messages d'erreur détaillés aux utilisateurs finaux. Utiliser des messages génériques tels que "Erreur de traitement" ou "Erreur de connexion".
    • Enregistrer les erreurs de manière sécurisée : Loguer les erreurs avec des détails suffisants pour le débogage, mais sans exposer des informations sensibles.
    • Mettre en place une surveillance des erreurs : Utiliser des outils de monitoring pour détecter et analyser les erreurs en temps réel.

  4. Protection contre les attaques par force brute :

    • Limiter le nombre de tentatives de connexion : Implémenter des mécanismes pour restreindre le nombre de tentatives de connexion par période de temps.
    • Utiliser des CAPTCHA : Ajouter des CAPTCHA pour les utilisateurs après un certain nombre d'échecs de connexion pour vérifier que l'utilisateur est bien un humain.
    • Implémenter des délais de blocage : Après plusieurs tentatives de connexion infructueuses, bloquer temporairement l'accès à l'utilisateur ou à l'adresse IP.

1.4 Suivi de la sécurisation

Le système actuel présente plusieurs lacunes en matière de suivi de la sécurité. Premièrement, il n'existe pas de processus systématique pour surveiller et analyser les nouvelles vulnérabilités ou les menaces potentielles, ce qui expose le système à des risques non détectés. De plus, le manque de mécanismes de surveillance continue rend impossible la détection en temps réel des activités suspectes ou anormales, ce qui pourrait permettre à des intrusions de passer inaperçues. Enfin, il n'y a pas de plan pour réaliser régulièrement des audits de sécurité afin d'évaluer et renforcer la posture de sécurité du système, ni de processus pour mettre à jour régulièrement les bibliothèques et les dépendances, ce qui expose le système à des vulnérabilités connues et non corrigées.

Pour remédier à ces problèmes, plusieurs solutions avaient été envisagées mais n'ont pas pu être mises en œuvre par manque de temps. Parmi celles-ci, l'intégration d'un système de gestion des vulnérabilités tel que Snyk pour surveiller les dépendances et identifier les failles connues était prévue afin de garantir une vigilance continue sur les composants utilisés. De plus, la mise en place d'un système de détection d'intrusion (IDS) comme Snort aurait permis de surveiller en temps réel les activités réseau et de détecter rapidement les comportements anormaux. Enfin, l'utilisation d'outils tels que Dependabot pour automatiser la mise à jour des bibliothèques aurait assuré que toutes les dépendances sont à jour et exemptes de vulnérabilités. Ces mesures auraient renforcé la sécurité du système en apportant une surveillance proactive et une maintenance régulière.

1.5 Diagramme de flux de données

image

2. Sécurisation

  • proxy cloudfare
  • les ports sont bloqués, on passe via un tunnel cloudfare ( port ouvert : 443 )
  • requête sql sécurisé
  • middleware qui intercepte les requête pour vérifier si un utilisateur est connecté
  • mot de passe hashed dans la db
  • utilisation de variable d'environement
  • login et signup classique

3. Validation de la sécurité

Dans ce projet, on n'a pas encore mis en place toutes les mesures de sécurité qu'on aurait voulu, mais voici ce qu'on a prévu de faire pour renforcer l'application avec les moyens qu'on a.

  1. Utilisation d'outils de vérification de la sécurité :

    • Situation actuelle : On n'a pas utilisé d'outils comme OWASP ZAP ou SonarQube pour vérifier la sécurité de notre code. Ça veut dire qu'il peut y avoir des failles comme des injections SQL ou des failles XSS qu'on n'a pas vues.
    • Actions recommandées : On pourrait commencer à utiliser des outils gratuits et faciles à trouver. OWASP ZAP, par exemple, est super pour détecter des failles de base, et SonarQube, même dans sa version gratuite, peut nous aider à analyser notre code pour trouver des problèmes de sécurité.

  2. Pentest externe :

    • Situation actuelle : On n'a pas fait de tests de pénétration avec des pros pour voir comment notre application réagirait à des attaques.
    • Actions recommandées : On pourrait essayer de participer à des programmes de bug bounty ou demander de l'aide à des étudiants en sécurité informatique pour qu'ils fassent des tests sur notre application. Ça nous donnerait des idées pour améliorer la sécurité sans avoir à payer pour des services chers.

  3. Audit de sécurité interne :

    • Situation actuelle : On n'a pas encore fait d'audit de sécurité interne pour voir où sont les failles potentielles.
    • Actions recommandées : On peut se réunir entre nous pour revoir le code et vérifier les aspects de sécurité de base. Il y a des checklists en ligne qu'on peut utiliser pour repérer des failles courantes. Faire ça régulièrement nous aiderait à identifier et corriger les problèmes de sécurité avant qu'ils ne deviennent sérieux.

Même si on n'a pas encore pu mettre en place toutes ces actions, ce sont des étapes importantes à envisager pour renforcer la sécurité de notre application avec les moyens qu'on a. Utiliser des outils gratuits, collaborer avec d'autres étudiants, et vérifier notre code en équipe sont des moyens simples et efficaces pour améliorer la sécurité dans le cadre de ce projet étudiant.

4. Cadre légal

4.1 Contraintes légales

4.1 Contraintes légales

Pour notre projet ScapeGame, plusieurs contraintes légales doivent être prises en compte afin de garantir la conformité de notre application aux régulations en vigueur. Voici les principales contraintes identifiées :

  1. Protection des données personnelles : Conformément au RGPD (Règlement Général sur la Protection des Données) applicable en Europe, nous devons assurer la protection des données personnelles des utilisateurs. Cela inclut la collecte, le stockage, le traitement et le partage des données de manière sécurisée et transparente. Les données sensibles doivent être cryptées, et les utilisateurs doivent avoir la possibilité de consulter, modifier ou supprimer leurs données personnelles.

  2. Respect des droits d'auteur : L'application utilise du contenu qui pourrait être protégé par des droits d'auteur, tels que des images, des musiques ou des textes. Il est impératif de s'assurer que tout contenu utilisé est soit libre de droits, soit correctement licencié, avec les autorisations nécessaires obtenues.

  3. Obligations en matière d'accessibilité : En vertu des directives sur l'accessibilité des sites web et des applications mobiles (WCAG 2.1), l'application doit être accessible à tous les utilisateurs, y compris ceux ayant des handicaps. Cela inclut des fonctionnalités telles que la compatibilité avec les lecteurs d'écran, des contrastes suffisants et des textes descriptifs pour les images.

  4. Réglementation sur la sécurité des informations : L'application doit respecter les normes de sécurité informatique pour protéger contre les cyberattaques. Cela inclut la mise en place de pare-feu, la gestion des accès et la surveillance des activités suspectes.

4.2 Mise en oeuvre de ces contraintes

Pour garantir le respect des contraintes légales mentionnées ci-dessus dans le cadre de ScapeGame, nous avons mis en place plusieurs mesures spécifiques :

  1. Gestion des données personnelles :

    • Cryptage des données : Les données des utilisateurs sont chiffrées à l'aide d'algorithmes robustes pour éviter tout accès non autorisé. Cela inclut les données stockées dans notre base de données (db.sql dans le dossier DB) et les informations transmises via l'application.
    • Consentement explicite : Lors de la création de comptes ou de l'utilisation des services, les utilisateurs doivent fournir un consentement explicite pour la collecte et l'utilisation de leurs données. Cette politique est détaillée dans les conditions d'utilisation accessibles depuis l'application.
    • Accès aux données : Les utilisateurs ont la possibilité de consulter, modifier ou supprimer leurs données personnelles via des interfaces sécurisées dans l'application.

  2. Respect des droits d'auteur :

    • Vérification des licences : Nous avons effectué une vérification rigoureuse pour nous assurer que tout contenu utilisé dans l'application est sous licence appropriée. Cela comprend les images, les musiques et les bibliothèques de code mentionnées dans package.json du dossier backend.
    • Utilisation de contenus libres de droits : Autant que possible, nous utilisons des ressources libres de droits pour minimiser les risques de violation de droits d'auteur.

  3. Accessibilité :

    • Compatibilité avec les technologies d'assistance : L'application a été testée pour être compatible avec les lecteurs d'écran et autres technologies d'assistance, garantissant ainsi une accessibilité maximale.
    • Conception inclusive : Les interfaces utilisateur ont été conçues en tenant compte des meilleures pratiques en matière d'accessibilité, notamment en termes de navigation, de contraste et de description des contenus.

  4. Sécurité des informations :

    • Mise en place de pare-feu et de surveillances : Des pare-feu et des systèmes de surveillance sont en place pour détecter et prévenir les cyberattaques. Le code dans swagger.js et swagger-ui.js du dossier backend assure une documentation claire des API pour une gestion sécurisée des accès.
    • Gestion des accès : Les droits d'accès aux différentes parties de l'application sont strictement contrôlés et attribués en fonction des rôles des utilisateurs.

5. Bilan et Limites

Bien que nous ayons travaillé sur la sécurité, nous sommes bien loin d'un résultat dit suffisant. Nos requêtes SQL sont bien écrites, mais l'API n'est pas assez sécurisée et permet des injections SQL. Le middleware nous protège seulement pour les utilisateurs non connectés et nous avons d'autres problèmes comme le XSS que nous n'avons pas eu le temps de traiter.