-
Notifications
You must be signed in to change notification settings - Fork 2
Sécurisation de l'application
Nous avons découpé notre site en 4 composantes principales:
- La base de données
C'est elle qui nous permet de stocker les données non seulement des utilisateurs mais aussi de toutes les ressources nécessaires au bon fonctionnement du site web. Elle ne doit pas être accessible d'une quelconque façon depuis l'extérieur et doit donc être le plus sécurisé et le plus confidentiel possible car le site dépend des données qu'elles contient.
- Le backend qui, grâce à l'api , effectue les requêtes vers la base de données.
C'est elle qui est en contact direct avec notre base de données. Une attaque réussite sur le backend causerais beaucoup de dégât et pourra éventuellement donner un accès au ressource de la base de données. Cette partie du site n'est pas visible par les utilisateurs et c'est elle qui va contenir le maximum de vérification possible pour les entrées et sorties des utilisateurs
-
Le frontend qui offre un visuel au client et permet de récupérer les informations qu'il fournit.
-
Le serveur web qui va héberger le site web à proprement dis (back et front).
Classez ces menaces en fonction du risque.]
-
Le port de la DB ne doit pas être exposé à internet: Rendre la base de données accessible uniquement par l'API.
-
Pas de mots de passes en clair dans le GitHub.
-
Changer les mots de passe par défaut.
-
DDoS: Une attaque par déni de service distribué, est un type de cyber attaque qui tente de rendre un site Web ou une ressource réseau indisponible en le saturant de trafic malveillant afin de l'empêcher de fonctionner. l'attaquant submerge sa cible avec du trafic Internet indésirable, si bien que le trafic normal ne peut pas atteindre sa destination.
-
Chiffrer les données Les données de celui-ci seront cryptées de sorte que dans le pire des cas, même si un attaquant met la main sur notre base de données, il ne sera pas en mesure d'exploiter ses données.
Surcharger les ressources d’une base de données afin de faire tomber le serveur
Risque : Extorsion des données, plantage de serveur
- Injections flaws ou SQL: Etant donnée que nous utilisons comme base de données postgresql nos requêtes depuis le backend vers la base de donnée se font grâce aux language sql. Et donc des injection sql vers notre backend ne sont pas évitable.
La probabilté de réussite d'une injection sql vers notre backend est de 1 sur une echelle de 1 à 5. S'il advenait qu'un telle attaque réussissent cela conduirait à une extorsion des données utilisateurs en backend ou bien même un contrôle totale sur le site web
- Broken authentification:
Un mauvaise mise en oeuvre des politiques de sécurité peuvent conduire à un controle totale du site. Elle se produit généralement via:
Un Attaque Bruteforce : Lorsque l'application autorise les mots de passe faible pour l'utilisateur ou l'administrateur. La probabilité de réusssite d'une telle attaque sur notre site est de 1 sur une echelle de 1 à 5. Se référer au contre-mesure adopté. Car la réussite d'un telle attaque donnera à l'attaquant un accès non autorisé au site.
Un Détournement de session : Lorsque l'application expose l'id de session ou que cet id de session à une durée de vie illimité. La probabilité de réussite d'un telle attaque sur notre site est de 1.5 sur une echelle de 1 à 5. Se référer au contre-mesure adopté. La réussite d'une telle attaque donnera accès à l'attaquant à la session d'un utilisateur et à ses informations personnelles.
Mauvaise configuration CORS qui autorise l'accès non autorisé à l'API. La probabilité de réussie d'une telle attaque sur notre site est de 2 sur une echelle de 1 à 5 La réussite d'un telle attaque donnera accès à l'attaquant au donnée dans la db.
- Server XSS (Cross Site Scripting)
Lorsqu'un attaquant envoie du code malveillant à plusieurs utilisateurs qui sont rendus par le navigateur de ceux ci. La réussite d'une telle attaque donnera accès à l'attaquant aux informations personnelles de l'utilsateur en question. La probabilité de réussite d'une telle attaque est de 1.5 sur 5. voir les contres mesures adopté
-
Dans notre site web, vu qu'on peut voir les données et le code CSS utilise sur le site, il se peut avoir de l'injection du code CSS arbitraire. Ce risque pourra arrivé sur une échelle de 1 à 5 (5/5)
-
Impact: L'impact de ce type de vulnérabilité varie en fonction de la charge utile CSS fournie. Cela peut conduire à des scripts intersites ou à une exfiltration de données.
source: Lien
-
c'est un site de faille de sécurité qui va permettre d'injecter des modifications dans une page web qui peuvent provoquer des actions sur les navigateurs web . Ce risque peut se produire sur une échelle de 1 à 5 (4/5)
-
Impact
Les attaques XSS peuvent prendre le contrôle du compte de nos clients et voler des informations personnelles telles que des mots de passe, des numéros de compte bancaire , les données d'indentification personnel etc.
-
L'attaquant va envoyer à l'utilisateur authentifié une requête HTTP qui est falsifiée qui va pointé sur une action interne du site, afin que l'utilisateur entre ses données personnels que l'attaquant va récupérer. L'utilisateur devient alors complice de l'attaque sans même se rendre comptes. Ce risque pourra arriver sur une échelle de 1 à 5 (3/5)
-
Impact
Il peut entrainer des relations client endommager, transfert de fonds non autoriser, des vols de donné des utilisateurs et aussi des cookies de session volés.
sécuration des données:
- Nos données vont passer en clair dans les réseaux car elle ne seront pas cryptées (à par le mot de passe qui lui est déjà crypté par le code). Cette situation à de grande chance d'arriver, car juste avec wireshark on pourrait voler des données (5/5 en chance).
-
Impact:
Un vol de données grâce à cette technique aurait un gros impacte sur notre site, car ça toucherai à la vie privée de nos client. Il est donc impératif de mettre en place l'HTTPS pour régler ce problème.
DoS/DDoS:
- Le DoS est une pratique très répendue qui conciste à connecter un très grand nombre de fois avec un grand nombre d'appareils sur un même serveur. Cette pratique résulte à un crash du serveur qui ne peut pas recevoir autant de requêtes à la fois. Cette situation à des chances d'arriver (3/5 en chance).
-
Impact:
Une attaque DoS ou DDoS pourait complètement mettre à l'arrêt notre serveur Web et donc arrêter la diffusion de notre site. Cela aurait un énorme impacte coté responsable du site.
[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.]
Nous avons modifié le fichier de configuration /etc/postgresql/10/main/pg_hba.conf pour n'autoriser que l'adresse IP dans laquelle le back-end est stocké car personne d'autre que le back-end n'est supposé y avoir accès.
# Database administrative login by Unix domain socket
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all <IP du VPS> md5
# IPv6 local connections:
host all all ::1/128 md5
Utiliser un fichier d'environnement .env avec les identifiants de celle-ci.
Installer et demarrer le service fail2ban
Il bloque les adresses IP appartenant à des hôtes qui tentent de casser la sécurité du système, pendant une période configurable (mise en quarantaine). Il ralentit les attaques par force brute, de même que les attaques par déni de service et est également capable de bloquer les attaques distribuées.
Installer le package :
sudo apt install fail2ban -y
Démarrer le service
service fail2ban start
- Injection flaws ou sql
Afin de combler au mieux cette faille on à opter pour un ORM nommé sequelize qui nous permet en backend de ne pas directement ecrire du sql mais d'imposer une couche qui sera traduite tout d'abord en language sql avant d'effectuer des requête dans la base de données ce qui nous permet de ne pas directement ecrire du sql et donc assure un protection contre des injections.
Une autre façon de d'assurer un protection contre un telle attaque est une revus approfondie du code pour vérifier si les requêtes sont effectuées vers la db et retourne des messages d'erreur pas trop verbeux.
- Broken authentification:
Un Attaque Bruteforce : Afin de contrer cette attaque, on a une première vérification des mots de passe côté frontend pour voir s'ils répondent aux critères exigés puis une seconde vérification côté backend pour renforcer au mieux et eviter le cas où l'attaquant réussi à passer le premier niveau de vérification
Détournement de session : Afin de contrer cette attaque, un délai d'expiration de session est mis en place grâce au token. Lorsqu'un utilsateur se connecte, il a un token jwt à sa disposition qui représente sa session et ce token hashé à partir d'un phrase à une durée de vie de 24h dans le cas où l'utilisateur se déconnecte, le jeton devient directement invalide
Mauvaise configuration CORS : Par défaut l'accès aux ressources est refuser sauf celles qui sont publiques (les voitures) et donc on essaie au mieux de prendre en compte les erreurs CORS lors du developpement de l'application.
- Server XSS (Cross Site Scripting)
Afin de contrer cette attaque, nous validons d'abord les entrées utilisateurs grâce à la bibliothèque express-validator afin de n'autoriser qu'une certaine longueur de caractère ou encore de rendre obligatoire certains champs.
- Protéger le code avec l'OWASP(Open Web Application Security Project): fondation qui sert à prévenir les attaques sur le web
- Filtrer le code avec le Node JS : On a essayé d’adopter des bonnes pratiques de filtrage des données lorsqu’un utilisateur est amené à saisir une donnée quelconque
-
Mise en place de l'HTTPS pour crypter les données.
-
Mise en place d'un système qui propose un nombre limité de connections par minute.
[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? ]
[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? ]
Voici les outils qui sont/serons utilisé pour valider la sécurisation de notre site:
-
Zed Attack Proxy
-
Immuniweb
-
Web cookies Scanner
-
HostedScan
[Présentation des contraintes légales s'appliquant à votre application]
Une des contraintes la plus importante en Europe est le RGPD (Règlement général sur la protection des données).
Le RGPD applique des lois concernants l'utilisation des données privées des utilisateurs d'un site ou d'un service web. Elle a été adoptée en 2016 et est appliquée depuis 2018 pour tous site européen et touche également les sites hors-europe avec des clients européens.
Les 3 principales règles sont:
- Les sites web ne peuvent collecter que les données personnelles utiles à leurs activités professionnelles.
- Le client doit être informé que ces dites données sont collectées et il doit être en accord avec ce fait.
- Il faut aussi mettre en place une reconaissance d'un droit à l'oubli. Effectivement, l'utilisateur doit pouvoir retirer ses données personnelles des bases de données en cas d'atteinte à la vie privée.
C'est une information qui peut identifier une personne de deux manière:
-
Directement, comme un nom, une adresse ou un numéro de téléphone.
-
Indirectement, comme un produit qui est consommé, un hobby, etc.
Certaines données sont sensibles car elles peuvent amener à des préjugés (religion, opinion politique, etc) et c'est pourquoi il faut un accord de la part de l'utilisateur.
Un site web représentant une entreprise doit obligatoirement préciser:
- Son nom
- Son adresse géographique
- Ses coordonnées de contact directes
- Son numéro d'entreprise et son numéro de TVA
- Les codes de conduite auxquels l'entreprise est éventuellement soumise
https://viaverbia.be/fr/actualites/obligations-legales-sites-web-entreprises-belgique
[Explication de ce qui a été mis en place pour respecter le cadre légal dans le cadre de ce projet]
- Mise en place d'une section conditions d'utilisation et les contraintes légales.
Dans notre site web nous ajoutons un footer contenant les informations de la société ainsi que les conditions d'utilisation et les contraintes légales. Également, lorsqu'une personne crée un compte elle doit accepter ces conditions et nous lui proposerons un lien clicable vers celles-ci.
On doit également pouvoir supprimmer les données d'un client à sa demande. Nous prévoyons donc de mettre en place une page permettant à l'administrateur de supprimmer toutes les données en relation avec un des clients.
[D'après vous, est-ce que la sécurisation mise en place est suffisante? Pourquoi?]