TP TIW4 2019-2020 "authentification" : sécurisation d'une application (éducative) d'authentification
On donne une application d'authentification simple Node.js/Express avec un backend PostgreSQL qui doit gérer des comptes utilisateurs, appelons cette application LOGON.
Un serveur de développement Ubuntu 18.04 vous est fourni (une VM attribuée à chaque binôme dans Tomuss, le .pem vous sera communiqué) avec l'application LOGON déployée (mais l'application n'est en revanche pas lancée, voir la section lancement de l'application). Pour vous connecter sur par exemple 192.168.76.218, la commande ssh est ssh -i TIW4-VM-authentif.pem [email protected].
Le TP consiste en la sécurisation du serveur et de l'application LOGON, il est ainsi composé de deux parties :
- partie A on s'intéresse au niveau système et en particulier aux front nginx sur lequel il faut mettre en place HTTPS/TLS;
- partie B on s'intéresse à l'applicatif : le serveur d'application Node.js, la base de données PostgreSQL et surtout l'application elle même.
Le fichier BUILD.md donne des informations techniques sur le développement de l'application qui vous seront utiles pour déployer en local pour le développement en la partie B. Il est important de commencer ce TP en se familiarisant avec l'application. Une VM de démo est accessible à l'adresse http://192.168.76.199/
Un dossier zip est à rendre au plus tard le dimanche 20/10/19 à 23h59 10/11/19 à 23h59 dans la case idoine de Tomuss.
Votre serveur devra être en état de marche à cette date.
Le zip comprendra, voir le modèle de base fourni :
- Un fichier README.md avec toutes les informations administratives
- Le rapport d'au plus 1 page de la partie A au format pdf ET en markdown.
- Le rapport d'au plus 2 pages de la partie B au format pdf ET en markdown.
- Les annexes de la partie A d'au plus 4 pages
- Les annexes de la partie B d'au plus 8 pages
- L'ensemble des sources de votre application modifiée
Aucun autre format que .zip, .md et .pdf ne sera accepté. Le contenu spécifique de chaque partie du rapport sera détaillé dans la partie afférente.
Les critères d'évaluation sont les suivants, ils seront appréciés sur la base des rapports des annexes et de tests sur votre serveur :
- [20%] Qualité des documents (clarté, organisation, langue, mise en page)
- [30%] Exhaustivité des mesures de sécurité
- [30%] Qualité technique des mesures proposée (configuration ou dévellopement selon le cas)
- [20%] Qualité de l'expérience utilisateur
Sécurisez le serveur web qui vous est attribué. Regardez en particulier la mise en place de HTTPS/TLS sur nginx. Vous utiliserez a minima un certificat auto-signé généré avec OpenSSL et de préférence un certificat signé par l'autorité de certification nommé TIW4-SSI-CAW Certificate Authority dont le matériel cryptographique est donné dans le dossier ./ca-tiw4. Pour cela, vous générez un paire RSA, une demande CSR et un certificat signé de l'autorité pour votre IP. Voir quelques éléments sur OpenSSL et HTTPS/TLS dans la partie 2 du nouveau TP1 MIF03-CAW.
Pour vous guider, consulter :
- Pour nginx
- La doc Nginx http://nginx.org/en/docs/http/configuring_https_servers.html http://nginx.org/en/docs/http/ngx_http_ssl_module.html
- Les tutoriels https://www.linode.com/docs/web-servers/nginx/enable-tls-on-nginx-for-https-connections/ https://www.linode.com/docs/web-servers/nginx/tls-deployment-best-practices-for-nginx/
- https://cipherli.st/
- Pour OpenSSL
- Setup très complet de CA, avec autorité intermédiaire https://jamielinux.com/docs/openssl-certificate-authority/
- Gestion des passwords dans openssl https://stackoverflow.com/questions/4294689/how-to-generate-an-openssl-key-using-a-passphrase-from-the-command-line
- OpenSSL Command-Line HOWTO https://www.madboa.com/geek/openssl/ ou https://www.digitalocean.com/community/tutorials/openssl-essentials-working-with-ssl-certificates-private-keys-and-csrs
- Pour les recommandations sur HTTPS/TLS
Si la configuration du front nginx est au cœur du sujet, plus généralement, toutes les vulnérabilités niveau système et leurs contre-mesures sont pertinentes, à l'exclusion de la bases de données PostgreSQL et du serveur d'application Node.js qui seront traités en partie B.
La partie A du rapport sera composée comme suit :
- d'un tableau des mesures de sécurité mises en place, avec renvoi vers l'annexe. Le tableau constitue c'est l'essentiel du rapport. On donnera pour chaque mesure identifiée :
- une description du problème
- la mesure proposée et la justification de son choix
- un renvoi vers l'annexe pour les détails de la mesure technique et des de leurs justifications détaillée
- une conclusion sous la forme d'une évaluation de la sécurité vis-à-vis des bonnes pratiques de l'état de l'art
- les annexes : tous les scripts (config nginx, scripts bash des commandes OpenSSL) et références utiles à la description des mesures et leurs justifications.
Vous devez toujours pouvoir garantir un accès aux enseignants total aux enseignants : documentez toutes vos modifications et assurez vous de l'exhaustivité des informations !
Identifiez toutes les failles ou mauvaises pratiques de l'application web et prenez les mesures nécessaires pour sécuriser l'application et les comptes utilisateurs. Les aspects systèmes ayant été traités dans le TP précédent, cette partie est donc consacrée essentiellement à l'application et sa base de données. Votre attention sur la sécurité applicative portera en particulier sur :
- le stockage des mots de passes dans PostgreSQL (choix du hash)
- le processus d'authentification et de son maintien stateless (via JWT)
- le processus de création de compte (dureté du mot de passe, vérification de l'email, validité des saisies utilisateurs, mesures anti bots, limitations du nombre de tentatives)
- le processus de récupération du mot de passe (optionnel, via génération d'un token à validité limitée)
- la sécurité générale de l'application et les bonnes pratiques de développement NodeJS.
- la qualité de l'expérience utilisateur au delà de l'esthétique, c'est surtout les enchainements d'écrans et la clarté des retours/erreurs qui compte.
Pour vous guider, vous pouvez consulter :
- https://jwt.io/ la référence sur JSON Web Token
- https://cheatsheetseries.owasp.org/ recommandée, notamment les feuilles Password Storage et Authentication.
- https://github.com/goldbergyoni/nodebestpractices recommandée, notamment 6. Security Best Practices
- https://expressjs.com/en/guide/error-handling.html
- https://expressjs.com/en/advanced/best-practice-performance.html
- https://expressjs.com/en/advanced/best-practice-security.html
Remarque, si vous pouvez envoyer des emails via smtp.univ-lyon1.fr:25 avec par exemple nodemailer il est aussi demandé de simuler leur envoi, par exemple en affichant le contenu du mail supposé envoyé dans une page web.
Similairement à la précédente, la partie B du rapport sera composée comme suit :
- d'un tableau des mesures de sécurité et nouvelles fonctionnalités mises en place, avec renvoi vers l'annexe. Le tableau constitue c'est l'essentiel du rapport. On donnera pour chaque mesure identifiée :
- une description du problème
- la mesure proposée et la justification de son choix
- un renvoi précis (fichier et numéro de ligne) vers l'annexe pour les détails de la mesure technique et des de leurs justifications détaillée
- une conclusion sous la forme d'une évaluation de la sécurité vis-à-vis des bonnes pratiques de l'état de l'art
- les annexes : tous les extraits du code source, scripts et références utiles à la description des mesures ou fonctionnalités et de leurs justifications.
Vous veillerez en particulier à bien détailler les mesures/fonctionnalités relatives au point 1 à 4 cités plus haut (stockage des mots de passes, processus d'authentification, création de compte et récupération du mot de passe).
L'ensemble du code et des scripts nécessaires au déploiement (notamment les scripts SQL) est fournie dans une autre annexe générale.