Projet • Sécurité Web
| Champ | Valeur |
|---|---|
| Auteur·e | Élise C. Philippe |
| Édition | 2024-11-27 |
| Échéance | TBH |
| Taille des équipes | 2~4 personnes |
| Rendu | Soutenance et PDF sur Teams |
Introduction
Votre objectif, sécuriser votre API Web, et de vous préparer à sécuriser votre Frontend pour votre projet de fin de bachelor.
Vous allez apprendre comment :
- gérer et stocker des passes ;
- représenter une connexion ;
- révoquer une connexion ;
- les différentes méthodes pour se représenter une connexion (session vs. JWT) ;
- suivre les recommandations de l’OWASP ;
- recevoir des secrets (variables d’environnemet) ;
- gérer le CORS ;
- prévenir les injections ;
- gérer le CSRF.
De façon générale, le but c’est d’être capable d’implémenter des mesures de sécurité et les expliquer. Vous n’aurez pas besoin de tout implémenter vous même, car vos bibliothèques et frameworks gèrent au moins une partie des sécurités dont vous avez besoin. Votre objectif c’est d’être capable d’expliquer :
- pourquoi une sécurité est nécessaire et comment vous l’avez implémenté ?
- pourquoi une sécurité n’est pas nécessaire dans votre cas ?
Méthodologie
Utilisez un gestionnaire de projet pour votre groupe. Que ce soit des issues sit GitHub, sur la forge 89 ou n’importe quel outil qui vous convient. Utilisez des milestones ou des projets pour les différentes grandes familles d’issues à traiter.
Par exemple vous pouvez avoir des milestones ou des projets :
- Technique de l’API
- User Stories
- Sécurité Web
Entrez les tâches qui suivent dans votre gestionnaire de projet.
Tâches note 1 : Backend
Méthode d’évaluation
Lors d’une soutenance, vous devez démontrer la présence des critères qui suivent. Les critères qui ne sont pas abordés ne contribueront pas à votre note. Un manque de clarté dans vos explications vous fera perdre des points.
| Critères | Points Accessibles |
|---|---|
| Tâches | 14 |
| Explications, compréhension | 7 |
| Malus cumulables | -1 |
| Total | 20 |
Auth*
- [ ] Les passes sont hachés en argon2id en suivant reco OWASP.
- [ ] La comparaison entre un passe contre un hash, lors du login, fonctionne.
- [ ] Les passes ou leur hashes ne sont JAMAIS renvoyés en réponse de route.
- [ ] Les passes sont échangés contre un jeton de session ou un JWT.
- [ ] JWT : votre clé secrète doit être reçue via une variable d’environnement de votre choix. (risque de malus)
- [ ] Les routes sont protégées par une vérification du jeton de connexion sauf pour la consultation de quelques données publiques ou la connexion.
- [ ] Des rôles contraignent certaines actions à certains groupes d’utilisateurs.
- [ ] Des routes permettent des actions seulement lorsqu’elles portent sur des ressources appartenant à l’utilisateur connecté.
- [ ] Un mécanisme permet la déconnexion.
- [ ] Un mécanisme permet la révocation de TOUT les tokens ou de TOUTES les sessions encore valable pour un utilisateur.
Cors
- [ ] Le serveur répond au requêtes pré-vol (pre-flight) de CORS.
- En développement toutes les méthodes sont autorisées pour toutes les origines.
- En production une seule origine à le droit de faire toutes ces requêtes, choisissez un nom de domaine à vous ou quelque chose en
*.pfb.ecole-89.com.
- [ ] Le serveur ajoute aux requêtes GET les header CORS.
Secrets
- [ ] Les identifiants de connexion à votre base de données doivent être passés par variable d’environnement.
- [ ] Tout secret utilisé par votre programme doit être passé en variable d’environnement (sinon malus).
Injections
- [ ] Les données produites par des utilisateurs ne doivent pas pouvoir provoquer d’exécution arbitraire de code ACE ou de requête arbitraire en BDD. (Justifiez en montrant vos tentatives d’injections.)
CSRF
- [ ] Le besoin de protections aux CSRF côté serveur est identifié (et des protections sont implémentées si nécessaire)
Tâches note 2 : document
But : écrire un document qui résume les sécurités et contre mesures mises en place ainsi que celles qui sont nécessaires pour le frontend (et/ou celles qui sont déjà implémentées si le frontend est déjà commencé ou terminé) de sorte qu’une personne extérieure au projet puisse comprendre ce qui a été fait et ce qu’il reste à faire.
Pour la partie frontend, pensez aux mesures mises en place sur le back-end et à comment elles intéragissent ensemble. Pensez aussi au mesures qui sont exclusives au front.
Méthode d’évaluation
Sur rendu : PDF sur teams.
| Critère | PA OK | PA POK | PA NOK |
|---|---|---|---|
| Format (page de garde, numéros de page, sommaire) et ton du document |
5 : ton et format professionel | 2.5 : le format est partiellement professionel | 0 : le format n’est pas du tout professionel |
| Stratégie frontend | 7.5 : les étapes d’auth et de sécurisation du frontend sont claires et complèters | 3.75 : une partie des étapes n’est pas claire, il manque plusieurs éléments | 0 : il manque trop d’éléments pour que le document soit utile. |
| Stratégie backend | 7.5 : on comprend très bien les mesures de sécurité mises en place sur le backend | 3.75 : on comprend moyennement bien | 0 : les informations sont insuffisantes pour comprendre les mesures prises |