Sécu Web
On utilise le protocole HTTPS afin de chiffrer avec la communication entre l’utilisateur et le serveur. On utilise “Let’s Encrypt” afin de générer le certificat TLS/SSL.
Les sessions sont sauvegardées dans la table session en back end. Celle-ci contient 3 champs : le nom d’utilisateur, l’UUID de sessions et sa date de création. Un événement en DB tourne toutes les 10 minutes et supprime toutes les sessions vielles de 2 heures.
Lors de la connexion d’un utilisateur, on lui envoie l’UUID de session qui est sauvegardé dans un cookie. Le cookie est quant à lui, utilisable uniquement en HTTPS ; bloqué à notre site (ne peut pas être utilisé par des sites tiers) ; inaccessible en JavaScript et ne peut pas être manipulé avec l’API « Document.cookie » ; a une durée de vie de 2 heures et est signé pour nous assurer qu’il n’a pas été modifier en Front.
Les formulaires en front encadre l’utilisateur sur les données qu’il doit saisir (type, taille, obligatoire, etc.). En back, on utilise Express-Validator pour les vérifier et s’assurer qu’ils ont été utilisés comme attendu. Dans le cas contraire, la requête est rejetée.
Express validator est présent mais ne fonctionne pas, nous n'avons pas eu le temps de vérifier d'où venait le problème.
Les mots de passe n’ont pas de limitation de type de caractère, ont une taille comprise entre 8 et 64 charactères. Lors de l’authentification, on effectue une review du mot de passe pour guider l’utilisateur vers un résultat sécurisé.
Lors de l’envoi du front vers le back, le mot de passe est hashé en sha512 et salé avec un chaine fixe de 250 caractères.
Lors de l’inscription, on hash avec argon2 avec un sel aléatoire les mots de passe avant la sauvegarde en base de données.
Mise en place d’un captcha Google lors de l’inscription d’un utilisateur pour limiter le spam de requêtes et l’utilisation de bot.
Afin de se protéger des attaques DOS, on a mis en place une limite de requêtes pour chaque utilisateur. Ainsi un utilisateur ne pourra faire que X requêtes toutes les X minutes. Il n’y a pas de whitelist.
Pour lutter contre les injections, on a mis 2 choses en place. On utilise Express-Validator (formulaire) et des RegEx en back pour vérifier qu’il n’y a pas de caractères dangereux comme « \ ». S’il y a un problème, la requête est rejetée.
Le Cors a été configuré pour n’autoriser que les requêtes provenant de notre application, empêchant des sites tiers d’exploiter notre API. On restreint également les méthodes utilisables, seul le « GET, POST et DELETE » sont autorisés. On active l’option « Access-Control-Allow-Credentials » du header pour permettre la transmission de nos cookies de sessions.