Projet 4

17 mars 2022
Table des matières
1 Tableau des exigences 2

2 Liste des exigeances de sécurité 3

1
1 Tableau des exigences

Application global Fonction authentification Fonction commande de produit

Exigence 1
Exigence 2
Exigence 3
Exigence 4
Exigence 5
Exigence 6
Exigence 7
Exigence 8
Exigence 9
Exigence 10
Exigence 11

2
2 Liste des exigeances de sécurité
Exigeance 1 : Le mécanisme d’authentification doit reposer sur une méthode de sto-
ckage des informations d’identification sécurisée afin de protéger correctement les iden-
tités ainsi que les droits associés.

Vulnérabilité :

Solution : En cas de compromission de la base de données contenant des informations d’authenti-

fication nécessaires au vérifieur, il ne doit pas être possible pour un attaquant d’utiliser directement
ces informations afin d’usurper une identité. Il est recommandé d’utiliser un sel choisi aléatoirement
pour chaque compte et d’une longueur d’au moins 128 bits. et d’utiliser des fonctions de dérivation
de mots de passe memory-hard comme scrypt ou Argon2.

Exigeance 2 : L’application doit chiffrer correctement les informations sensibles lors

du stockage des données afin que les données chiffrées sur disque ne soient pas faciles
à déchiffrer.

Vulnérabilité :

Solution : Utiliser des algorithmes reconnus publiquement tels qu’AES, cryptographie à clé pu-
blique RSA, et SHA-256 ou mieux pour la fonction de hachage. Certaines données ne doivent jamais
être stockées, comme le contenu de la bande magnétique, le numéro de vérification d’une carte ou
le numéro d’identification personnel. Les données des titulaires de carte doivent être chiffrées avant
d’être stockées.

Exigeance 3 : L’application doit chiffrer correctement toutes les communications au-

thentifiées et sensibles.

Vulnérabilité :

Solution : Utiliser SSL pour toutes les connexions qui sont authentifiées ou qui transmettent des
données sensibles, comme des éléments d’authentification, les détails d’une carte de crédit, d’une
carte de santé ou autres informations privées. Assurer que les communications entre les compo-
sants d’une infrastructure, comme entre des serveurs WEB et des serveurs de bases de données,
sont protégées de façon appropriée grâce à l’utilisation d’une couche de transport sécurisée ou d’un
chiffrement au niveau protocole pour les éléments d’authentification et les données intrinsèques

3
Exigeance 4 : L’application doit limiter dans le temps le nombre de tentatives d’au-
thentification afin d’éviter les tentatives de brute-force.

Vulnérabilité :

Solution : Il est recommandé de mettre en œuvre un mécanisme limitant le nombre de tentatives

d’authentification sur une période de temps donnée, afin de réduire les probabilités d’authentifica-
tion frauduleuses par force brute.

Exigeance 5 : Mettre en place une politique de sécurité des mots de passe pour les
utilisateurs de l’application, afin de complexifier l’accès à un mot de passe en cas de
tentative de brute-force.

Vulnérabilité :

Solution : Il est recommandé de mettre en place une politique de sécurité des mots passe adaptée
au contexte et aux objectifs de sécurité du système d’information tels que la longueur minimal, le
délai d’expiration, les règles de complexité, les mécanismes de contrôle de la robustesse des mots
de passe etc

Exigeance 6 : Toutes les données fournies par les utilisateurs ne doivent en aucun cas
être utilisées pour modifier le sens des commandes ou des requêtes exécutées par les
interpréteurs SQL invoqués par l’application.

Vulnérabilité : (Command Injection)

Solution : Les requêtes adressées à la base de données doivent être faites au moyen de requêtes
préparées fortement typées ou par l’intermédiaire d’une couche d’abstraction assurant le contrôle
des paramètres. Il est également nécessaire de respecter le principe du moindre privilège lorsqu’une
connexion à la base de données ou tout autre système de back-office est établie. Toutes les données
fournies par les utilisateurs doivent répondre à des exigences strictes en matière de format, de lon-
gueur et d’attributs avant d’être validées.

Évitez d’utiliser des arguments d’URL, comme dans les modèles objet-relationnel (ORM), pour
déclencher des actions au sein des bases de données. Utilisez les commandes LIMIT dans les opé-
rations SQL afin de minimiser la divulgation des données au cas où votre base de données serait
touchée par une injection SQL. Les entrées en provenance des clients ne doivent pas être considérées
comme fiables et par conséquent, aucune vérification ne doit être déléguée aux clients.

4
Exigeance 7 : Le mécanisme des sessions doit être en mesure d’empêcher aux maxi-
mum, un utilisateur malveillant d’ obtenir des accès non autorisés à des sessions et
avoir accès à des données sensibles.

Vulnérabilité :

Solution : S’assurer que les identificateurs de session sont suffisamment ”aléatoires” : Les jetons de
session doivent être générés par des fonctions aléatoires sécurisées et avoir une longueur suffisam-
ment longue pour résister à l’analyse et à la prévision (entropie de 128 bits minimum). Implémenter
un temps d’expiration de la session : Après une période de connexion relativement longue (de 4
à 8 heures), les utilisateurs doivent être déconnectés. Ceci contribue à atténuer le risque qu’un
attaquant utilise une session détournée pendant une longue durée.

Détruire la session si un signe d’altération est détecté : Si l’application nécessite plusieurs sessions
simultanées pour un seul utilisateur, il est nécessaire d’implémenter des fonctionnalités pour détec-
ter les tentatives de clonage de session. Une fois un signe de clonage est détecté, la session doit être
détruite afin d’obliger l’utilisateur à s’authentifier de nouveau.Rendre la session invalide après la
déconnexion : Lorsque l’utilisateur se déconnecte de l’application, la session et les données corres-
pondantes sur le serveur doivent être détruites. Ceci garantit que la session ne soit accidentellement
rétablie.

Utiliser des attributs de cookies sécurisés (les flags httponly et secure) : Le cookie de session doit
être défini à la fois avec les flags HttpOnly et Secure. Ceci garantit que l’identifiant de session ne
soit accessible aux scripts côté client et soit transmis via SSL respectivement.

Exigeance 8 : Tous les paramètres doivent être validés dans le but de détecter d’éven-
tuelles d’attaques, avant d’être inclus dans les pages de l’application.

Vulnérabilité : (Cross-Site Scripting)

Solution : Disposer d’un mécanisme standard de validation d’entrée pour valider la longueur, le
type et la syntaxe de toute entrée saisie, ainsi que les règles de gestion avant d’accepter l’affichage
ou le stockage des données. Utiliser une stratégie de validation essentiellement basée sur l’accep-
tation de quelque chose de connu et rejeter toute entrée invalide plutôt qu’essayer d’assainir des
données potentiellement hostiles.

5
Exigeance 9 : Tous les paramètres doivent être encodés dans le but de d’empêcher
toute injection de script de se produire dans le navigateur, avant d’être inclus dans les
pages de l’application.

Vulnérabilité : (Cross-Site Scripting)

Solution : Appliquer un chiffrement robuste des données en sortie, les données écrites par l’uti-
lisateur doivent être convenablement codées par entité avant le rendu. L’application ne doit pas
décoder plusieurs fois la même entrée. De telles erreurs pourraient être employées pour contourner
les schémas de liste blanche en présentant des entrées dangereuses après qu’elles aient été vérifiées.

Définir l’encodage des en-têtes HTTP ou des méta-tags à l’intérieur de l’HTML. Le navigateur
n’aura pas besoin de déterminer le type d’encodage. Un paramétrage cohérent d’un codage, comme
UTF-8, permet de réduire les attaques de type ”Cross-Site Scripting”.Utiliser la Politique de Sé-
curité de Contenu (CSP) ou les en-têtes de protection ”X-XSS” : ces deux techniques aident à se
protéger contre les attaques réfléchies ”cross-site scripting” (XSS)

Exigeance 10 : L’application doit être en mesure d’accorder ou refuser l’accès à une

ressource ou une fonctionnalité spécifique, en fonction des droits initialement attribués.

Vulnérabilité :

Solution : S’assurer que toutes les pages de l’application, qui ne doivent pas être publiques, ont
un contrôle d’authentification. Le principe de moindre privilège doit être appliqué à l’ensemble
des éléments du système, si l’accès n’est pas explicitement permis, l’accès doit être refusé. Si un
utilisateur n’a d’autres besoins que de lire une colonne dans une table spécifique, l’administrateur
de base de données ne doit lui octroyer que ce droit.

Contrôler les droits de l’utilisateur quand une référence directe à un objet (ID) est effectuée avant
de lui retourner les ressources concernées. Les décisions de contrôle d’accès devraient être basées
sur l’identité de l’utilisateur qui s’authentifie ainsi que sur l’information de confiance du côté serveur.

Exigeance 11 : L’application ne doit en aucun cas divulguer à l’utilisateur, des infor-

mations importantes , à travers d’éventuels messages d’erreurs.

Vulnérabilité :

Solution : Bloquer les accès direct à l’arborescence des fichiers sur le serveur et à la pile d’infor-
mations. Les gestionnaires d’erreurs doivent être configurés pour gérer les erreurs inattendues et
contrôler minutieusement toutes les sorties possibles.