NOMS : ONDIYO CHRISTIAN CLASSE: BTS SIO SLAM INIT 1

DEVOIR DE CYBERSECURITE DES SERVICES

ETUDE DE CAS “Cas Lama Zoo”
Question A.1 :
a) Expliquer en quoi consiste une attaque par force brute et pourquoi elle a été
efficace pour compromettre le mot de passe de M. Breto.

Une attaque par force brute est une méthode utilisée par les attaquants pour obtenir un
accès non autorisé à un système ou à des données. Elle consiste à essayer
systématiquement toutes les combinaisons possibles de mots de passe jusqu'à trouver celui
qui permet l'accès au système ciblé. Cette technique peut être particulièrement efficace si le
mot de passe est faible, c'est-à-dire court, simple, ou faisant partie d'une liste de mots de
passe couramment utilisés et donc facile à deviner. Dans le cas de M. Breto, l'attaque par
force brute a été efficace probablement parce que son mot de passe était relativement
simple («1234Travail») et a pu être rapidement deviné par l'attaquant. De plus, la présence
du mot de passe noté au dos du clavier indique une pratique de sécurité faible, rendant le
mot de passe encore plus vulnérable à être découvert non seulement par des moyens
numériques mais aussi physiquement par toute personne ayant accès au poste de travail.

b) Citer au moins deux moyens de sensibiliser les employés aux enjeux de sécurité

Pour sensibiliser les employés aux enjeux de sécurité et éviter de tels incidents à l'avenir,
voici deux moyens efficaces :

Formation et sensibilisation à la sécurité informatique : Organiser des sessions de

formation régulières pour les employés afin de les sensibiliser sur l'importance de la sécurité
informatique, y compris les bonnes pratiques de création et de gestion des mots de passe.
Cela comprend l'explication des risques associés aux attaques par force brute et
l'importance d'utiliser des mots de passe complexes (longs, avec une combinaison de
lettres, chiffres et caractères spéciaux) et uniques pour chaque service.

Mise en place de politiques de sécurité renforcées et de solutions techniques : Imposer

des politiques de sécurité strictes, comme l'obligation d'utiliser des mots de passe forts et de
les changer régulièrement. L'utilisation de gestionnaires de mots de passe peut aussi être
encouragée pour aider les employés à gérer des mots de passe complexes sans avoir à les
noter ou à les oublier. En outre, l'implémentation de mesures techniques telles que
l'authentification à deux facteurs (2FA) pour l'accès aux systèmes critiques peut grandement
réduire le risque d'accès non autorisé, même si un mot de passe est compromis.

Question A.2 :

a) Indiquer en quoi ne pas avoir d’authentification sur l’application constitue un risque

de non-traçabilité.

Risque de non-traçabilité : L'absence d'authentification individuelle pour accéder à

l'application de gestion des ateliers empêche de déterminer qui a effectué quelle action au
sein de l'application. Cela signifie qu'en cas d'erreur, de manipulation malveillante ou de fuite
de données, il est impossible de retracer l'origine de ces incidents à un utilisateur spécifique.
La traçabilité des actions est cruciale pour la sécurité et la gestion des responsabilités au
sein d'une organisation.

b) Indiquer en quoi ne pas avoir d’authentification sur l’application constitue un risque

de perte de confidentialité

Risque de perte de confidentialité : Sans authentification, tous les employés ayant accès à
un poste de travail connecté peuvent accéder à l'application et potentiellement à des
informations sensibles sans restriction. Cela peut conduire à la divulgation non autorisée
d'informations confidentielles, que ce soit intentionnellement ou par négligence. La mise en
place d'un système d'authentification garantit que seules les personnes autorisées peuvent
accéder à des données sensibles, protégeant ainsi la confidentialité des informations.

Question A.3 :

Expliquer en quoi l’utilisation de différents rôles applicatifs au niveau du pilote de

connexion à la base de données dans l’application permet une meilleure sécurité des
données et des traitements dans l’application.

L'utilisation de différents rôles applicatifs au niveau du pilote de connexion à la base de

données dans l'application est une stratégie de sécurité informatique avancée, connue sous
le nom de gestion des habilitations ou contrôle d'accès basé sur les rôles (Role-Based
Access Control, RBAC). Ce modèle permet une meilleure sécurité des données et des
traitements pour plusieurs raisons :

Séparation des privilèges

En attribuant à chaque utilisateur un rôle spécifique qui détermine ses droits d'accès aux
données et aux fonctionnalités de l'application, on s'assure que les utilisateurs ne disposent
que des permissions strictement nécessaires à l'exécution de leurs tâches. Cela limite les
risques de fuites de données ou d'actions malveillantes, car un utilisateur ne peut accéder
qu'aux informations et aux opérations autorisées par son rôle.

Minimisation des risques de sécurité

En limitant les droits d'accès des utilisateurs aux seules ressources dont ils ont besoin, on
réduit la surface d'attaque potentielle. Cela empêche les utilisateurs (qu'ils soient malveillants
ou non) d'exploiter des permissions excessives pour accéder à des informations sensibles
ou effectuer des actions non autorisées. Cela aide également à prévenir les dommages
accidentels, tels que la suppression de données critiques.

Contrôle d'accès granulaire

Les rôles applicatifs permettent un contrôle d'accès plus granulaire aux données. Au lieu
d'avoir un accès général à la base de données, les utilisateurs obtiennent des droits
spécifiques sur certaines tables, enregistrements ou champs, selon les besoins de leur rôle.
Cela assure que les données sensibles restent protégées et que chaque utilisateur ne peut
voir ou modifier que ce qui lui est explicitement permis.

Audit et traçabilité

Avoir des rôles définis pour chaque utilisateur facilite l'audit et la traçabilité des actions
effectuées au sein de l'application. En cas d'incident de sécurité ou de besoin de révision
des accès, il est plus facile de vérifier qui avait accès à quoi et d'identifier la source d'une
éventuelle compromission. Cela est essentiel pour répondre aux normes de conformité et
aux réglementations en matière de protection des données.

Simplification de la gestion des politiques de sécurité

La gestion centralisée des rôles et des habilitations simplifie l'administration de la sécurité.

Au lieu de configurer les permissions pour chaque utilisateur individuellement, les
administrateurs peuvent gérer des groupes de permissions à travers des rôles. Cela rend les
modifications des politiques de sécurité plus agiles et moins sujettes aux erreurs, car une
modification d'un rôle se répercute automatiquement sur tous les utilisateurs associés à ce
rôle.

Question A.4 :

a) Indiquer pourquoi ces manques sont des sources de vulnérabilité en matière de

sécurité.

Sources de vulnérabilité en matière de sécurité

Habilitations sans durée de vie : L'absence de durée de vie pour les habilitations crée un
risque de sécurité majeur, surtout dans un environnement où les employés changent
régulièrement de rôle ou où des stagiaires et saisonniers sont employés. Sans expiration
automatique des droits d'accès, des utilisateurs pourraient conserver un accès inapproprié à
des ressources ou des données sensibles longtemps après que leur nécessité ou légitimité
d'accès a cessé. Cela ouvre la porte à des abus potentiels ou à des failles de sécurité si ces
comptes sont compromis.

Multiples rôles pour la même application : Permettre à un utilisateur d'avoir plusieurs rôles
pour la même application peut compliquer la gestion des droits d'accès et mener à une
accumulation de privilèges. Ce sur-ensemble de privilèges peut aller au-delà de ce qui est
nécessaire pour les fonctions actuelles de l'employé, violant ainsi le principe de moindre
privilège. Cela augmente le risque que des données soient accessibles par des utilisateurs
n'ayant pas besoin de cet accès pour leur rôle actuel, ou que des actions soient effectuées
au-delà de ce qui est autorisé pour leur poste.

b) Proposer les modifications de la base de données corrigeant ces problèmes

Modifications de la base de données pour corriger ces problèmes

1. Ajouter une durée de vie aux habilitations : Pour chaque rôle attribué à un utilisateur,
ajouter un champ "Date de fin" représentant la fin de la validité de ce rôle. Cela permet
d'assurer que les droits d'accès sont automatiquement révoqués à une date spécifique, ce
qui est particulièrement utile pour gérer les accès de stagiaires et de saisonniers, ou
lorsqu'un employé change de rôle.

2. Restriction à un rôle unique par application et utilisateur : Modifier la structure de la

base de données pour qu'un utilisateur ne puisse avoir qu'un seul rôle actif par application à
tout moment. Cela peut être réalisé en s'assurant que la combinaison "Utilisateur-
Application" soit unique dans la table d'habilitation. Si un changement de rôle est nécessaire,
l'ancien rôle doit être explicitement retiré ou modifié pour refléter le nouveau rôle de
l'utilisateur.
Implémentation technique :

• Table des habilitations : Ajouter des champs DateDebut et DateFin pour chaque
habilitation, permettant de définir clairement quand les droits d'accès commencent et
quand ils se terminent.
• Contrainte d'unicité : S'assurer que la table qui lie les utilisateurs, leurs rôles, et les
applications impose l'unicité de la combinaison utilisateur-application. Cela peut être
accompli par une clé primaire composite ou une contrainte d'unicité.
• Scripts de maintenance : Mettre en place des routines automatisées qui vérifient
régulièrement les dates d'expiration des habilitations et retirent ou mettent à jour les
droits d'accès en conséquence.

Ces modifications aideront à minimiser les risques de sécurité en s'assurant que les accès
sont accordés de manière appropriée, conformément au principe de moindre privilège, et
que les habilitations sont maintenues à jour en fonction des changements de rôle ou de
statut des employés.

Question A.5 :

Écrire le code du déclencheur after_update_habilitation permettant l’historisation des

modifications d’habilitations dans la table EstHabilite.

Pour créer un déclencheur after_update_habilitation qui historise les modifications

d'habilitations dans la table EstHabilite, il faut tenir compte du système de gestion de bases
de données (SGBD) utilisé, car la syntaxe peut varier. Néanmoins, je vais vous fournir un
exemple générique basé sur le SQL standard, souvent utilisé dans des SGBD comme
PostgreSQL, MySQL, ou SQL Server, avec des ajustements mineurs nécessaires selon le
SGBD spécifique.

Le déclencheur se déclenchera après qu'une modification a été faite sur un enregistrement

dans la table EstHabilite. Il insérera un enregistrement dans la table HistoHabilitation qui
contiendra le timestamp de l'action, le numéro de matricule de la personne, l'ID de
l'application concernée, et un message décrivant le changement de rôle.

Voici un exemple de code pour PostgreSQL, car il permet une bonne flexibilité pour ce type
d'opération. Notez que pour d'autres SGBD, la syntaxe exacte et les fonctions disponibles
peuvent différer.

CREATE OR REPLACE FUNCTION after_update_habilitation()

RETURNS TRIGGER AS $$
BEGIN
INSERT INTO HistoHabilitation(dateheure, numMatriculePerso, idAppli, action)
VALUES (NOW(), OLD.numMatricule, OLD.idAppli,
'Modification du rôle [' || OLD.idRole || '] à [' || NEW.idRole || ']');
RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER after_update_habilitation_trigger

AFTER UPDATE ON EstHabilite
FOR EACH ROW
WHEN (OLD.idRole IS DISTINCT FROM NEW.idRole)
EXECUTE FUNCTION after_update_habilitation();

Ce script crée une fonction after_update_habilitation et un déclencheur

after_update_habilitation_trigger qui est activé après chaque mise à jour sur la table
EstHabilite. La condition WHEN (OLD.idRole IS DISTINCT FROM NEW.idRole) s'assure que
le déclencheur ne s'exécute que si le rôle de l'utilisateur a effectivement changé, pour éviter
de remplir la table d'historique avec des modifications non pertinentes.

Si vous utilisez un autre SGBD, vous devrez peut-être ajuster la syntaxe. Par exemple, SQL
Server utilise AFTER UPDATE AS au lieu de FOR EACH ROW et aura des différences dans
la façon de déclarer les fonctions. MySQL a également sa propre syntaxe pour la création de
triggers et de fonctions.

Question A.6 :

a) Expliquer l’intérêt d’utiliser des transactions pour réaliser ces opérations.

Intérêt d'utiliser des transactions pour ces opérations

L'utilisation de transactions pour réaliser les opérations de création et de suppression de

rôles applicatifs présente plusieurs avantages significatifs, notamment en termes de sécurité
des données, de cohérence, et de fiabilité du système de gestion de bases de données
(SGBD) :

Atomicité : Les transactions garantissent que toutes les opérations au sein d'une transaction
sont exécutées comme une seule unité de travail. Soit toutes les opérations réussissent, et la
transaction est validée (commit), soit si une opération échoue, toutes les modifications sont
annulées (rollback). Cela est crucial lorsqu'on manipule des comptes utilisateurs et des rôles
dans la base de données, car cela évite des états intermédiaires où certaines opérations
seraient appliquées tandis que d'autres échoueraient, menant à une incohérence des
données.

Cohérence : Les transactions maintiennent la cohérence de la base de données en

s'assurant que celle-ci passe d'un état valide à un autre état valide. Les contraintes
d'intégrité, comme les clés étrangères entre la table des rôles et les comptes utilisateurs,
sont respectées tout au long de la transaction.

Isolation : Les mécanismes d'isolation des transactions permettent de contrôler le degré de

visibilité des modifications faites par une transaction aux autres transactions simultanées.
Cela prévient les problèmes liés à la concurrence, comme les lectures sales, les non-
répétabilités de lecture ou les phénomènes fantômes, garantissant ainsi que chaque
transaction est effectuée comme si elle était la seule à s'exécuter dans le système.

Durabilité : Une fois qu'une transaction est validée, ses modifications sur la base de
données sont permanentes, même en cas de panne du système. Cela assure que les
opérations liées à la gestion des rôles et des comptes utilisateurs ne seront pas perdues et
que la base de données reflète fidèlement toutes les actions effectuées.
b) Compléter le code de la fonction deleteRole()

Voici un exemple générique de la fonction deleteRole() en SQL, utilisant une transaction

pour s'assurer que la suppression d'un rôle applicatif est traitée de manière atomique et
cohérente. Cet exemple suppose l'utilisation d'un SGBD qui supporte les transactions SQL
standard, comme PostgreSQL, MySQL (InnoDB), ou SQL Server.

CREATE OR REPLACE FUNCTION deleteRole(roleName VARCHAR)

RETURNS VOID AS $$
BEGIN
-- Début de la transaction
BEGIN;

-- Tentative de suppression du compte utilisateur dans le SGBD

-- La syntaxe exacte dépend du SGBD utilisé
EXECUTE 'DROP USER ' || roleName;

-- Suppression de l'enregistrement correspondant dans la table RoleApplicatif

DELETE FROM RoleApplicatif WHERE roleName = roleName;

-- Validation de la transaction si les deux opérations réussissent

COMMIT;
EXCEPTION
WHEN OTHERS THEN
-- Annulation de la transaction en cas d'erreur
ROLLBACK;
-- Lever une exception ou gérer l'erreur selon le besoin
RAISE;
END;
$$ LANGUAGE plpgsql;

la syntaxe spécifique pour la suppression du compte utilisateur (DROP USER) peut varier
selon le SGBD, et il peut être nécessaire d'ajuster cette commande en fonction de votre
environnement spécifique. De même, la gestion des exceptions (EXCEPTION WHEN
OTHERS THEN) est illustrée ici dans le contexte de PostgreSQL (plpgsql). Pour d'autres
SGBD, le mécanisme de gestion des erreurs et la syntaxe des transactions pourraient
nécessiter des ajustements

Dossier B : Sécurisation du recueil des avis des participants aux ateliers

Question B.1 :
a) Expliquer le rôle de la méthode before de la classe AuthGuard.
Dans le contexte d'un framework de développement web comme CodeIgniter, la
classe AuthGuard est typiquement utilisée pour gérer l'authentification des
utilisateurs. La méthode before de cette classe joue un rôle crucial dans le contrôle
d'accès aux différentes parties de l'application.
Son principal objectif est d'intercepter les requêtes avant qu'elles n'atteignent les
contrôleurs de l'application. La méthode before vérifie si l'utilisateur est authentifié et
autorisé à accéder à la ressource demandée. Si l'utilisateur n'est pas authentifié, ou
si les vérifications de sécurité échouent, cette méthode peut rediriger l'utilisateur
vers une page de connexion, afficher un message d'erreur, ou prendre toute autre
mesure de sécurité appropriée. Cela empêche l'accès non autorisé aux
fonctionnalités et aux données sensibles de l'application.
En résumé, la méthode before dans AuthGuard :
Intercepte les requêtes avant qu'elles n'accèdent aux contrôleurs.
Vérifie l'authentification de l'utilisateur, en s'assurant qu'il est connecté.
Contrôle l'accès aux ressources en fonction de l'authentification et des autorisations
de l'utilisateur.
Redirige ou bloque les requêtes non autorisées, contribuant ainsi à sécuriser
l'application.

b) Expliquer si un attaquant a besoin d’être préalablement authentifié pour

insérer un commentaire dans le formulaire de saisie des avis.
La question de savoir si un attaquant doit être préalablement authentifié pour insérer
un commentaire dans le formulaire dépend de la manière dont l'application est
configurée, en particulier de l'utilisation de la méthode before de la classe
AuthGuard.
Si la méthode before de AuthGuard est configurée pour exiger une authentification
avant de permettre à un utilisateur de soumettre un commentaire, alors oui,
l'attaquant aurait besoin d'être authentifié. Cette configuration est recommandée
pour des raisons de sécurité, car elle permet de limiter les actions que peuvent
effectuer les utilisateurs non authentifiés, réduisant ainsi le risque d'attaques
malveillantes, y compris les attaques de type XSS.
Cependant, si l'application permet aux utilisateurs non authentifiés de soumettre des
commentaires, un attaquant pourrait exploiter cette faille de sécurité pour insérer du
contenu malveillant, tel que du code JavaScript dans le cas d'une attaque XSS, sans
avoir besoin de s'authentifier. Cela souligne l'importance d'appliquer des contrôles
d'accès appropriés et de nettoyer les entrées utilisateur pour se protéger contre les
vulnérabilités XSS et autres menaces de sécurité web.
Question B.2 :
a) Expliquer pourquoi il s'agit ici d'une attaque XSS stockée.
a) Il s'agit d'une attaque XSS stockée car le code malveillant envoyé par l'attaquant
(via le formulaire de saisie des avis) est enregistré dans la base de données du site
Web. Lorsque d'autres utilisateurs consultent la page présentant les avis, le code
malveillant est récupéré de la base de données et exécuté par leur navigateur, ce qui
le distingue d'une attaque XSS reflétée, où le code malveillant est transmis
directement par l'URL.
b) Expliquer pourquoi une attaque de type XSS stocké est susceptible de
toucher un plus grand nombre de visiteurs du site Web qu'une attaque XSS
reflété
b) Une attaque XSS stockée est susceptible de toucher un plus grand nombre de
visiteurs car le code malveillant reste enregistré dans la base de données et est servi
à tous les utilisateurs qui accèdent à la page contenant l'avis malveillant.
Contrairement à l'attaque reflétée, où le code malveillant doit être envoyé à chaque
victime dans une URL spécialement conçue et où l'exécution dépend de l'interaction
de l'utilisateur avec cette URL, l'attaque stockée ne nécessite aucune action
supplémentaire de la part de l'attaquant une fois le code malveillant publié.

Question B.3 :
a) Donner au moins un argument lié à la sécurité expliquant pourquoi il est
conseillé de filtrer les données issues de la base de données avant leur
affichage sur le site.
Filtrage des données pour la sécurité
a) Filtrer les données avant l'affichage : Cela empêche l'exécution de scripts
malveillants stockés dans la base de données, protégeant ainsi les utilisateurs contre
les attaques XSS stockées. Cela garantit que tout code malveillant qui a pu être
introduit dans la base de données ne sera pas exécuté dans le navigateur de
l'utilisateur, protégeant ainsi l'utilisateur contre le vol de données sensibles, telles que
les cookies de session.
b) Donner au moins un argument lié à la sécurité expliquant pourquoi il est
conseillé de filtrer les données issues du formulaire avant leur écriture en base
de données.
b) Cela empêche le stockage et la propagation de scripts malveillants via la base de
données. En validant et nettoyant les données entrantes, on s'assure que seules les
informations sûres sont enregistrées, réduisant ainsi le risque d'attaques XSS
stockées et garantissant l'intégrité des données stockées.
Question B.4 : Neutralisation du code JavaScript avec CodeIgniter
a) Modifier la méthode commentStore de la classe AteliersController pour
neutraliser le code JavaScript lors de l'enregistrement dans la base de
données. (Ne recopier que les lignes modifiées en précisant leur numéro.)
Supposons que la méthode commentStore soit structurée de manière standard pour
un contrôleur dans CodeIgniter. Pour neutraliser le code JavaScript lors de
l'enregistrement, vous devez utiliser la fonction esc() fournie par CodeIgniter sur
toutes les données entrantes avant de les enregistrer dans la base de données.
// Supposons que le numéro de ligne avant modification soit 25
$data['comment'] = esc($this->request->getPost('comment'));

b) Modifier le code de la vue coms.php afin d’empêcher l’exécution du code

JavaScript lors de l'affichage des données. (Ne recopier que les lignes
modifiées en précisant leur numéro.
Modification du code de la vue coms.php :
Lors de l'affichage des données, utilisez également la fonction esc() pour neutraliser
tout code JavaScript potentiellement malveillant. Cela garantit que les données
affichées sont sécurisées contre l'exécution de scripts.
// Supposons que le numéro de ligne avant modification soit 42
echo esc($comment->text);

Ces modifications garantissent que l'application traite les données de manière

sécurisée, tant à l'entrée (lors de la réception des données du formulaire) qu'à la
sortie (lors de l'affichage des données à l'utilisateur), conformément aux meilleures
pratiques de sécurité pour prévenir les attaques XSS.

Dossier C : Sécurisation des activités liées au parrainage d’animaux Note : Ce

dossier utilise les documents C1 à C6 et les documents A4, B3 et B4

Question C.1 :
Observer le courriel reçu par M. Hardi et citer cinq types d’indices qui laissent
penser qu’il s’agit bien d’un hameçonnage.
C.1 : Indices de hameçonnage
Bien que je ne puisse pas observer directement le courriel reçu par M. Hardi, les
indices typiques qui suggèrent qu'il s'agit d'un hameçonnage incluent :
Adresse de l'expéditeur suspecte : L'adresse e-mail peut ressembler à celle du
parc zoologique mais avec de légères modifications ou fautes d'orthographe qui ne
seraient pas évidentes à première vue.
Liens douteux : Le courriel contient probablement des liens qui semblent légitimes
mais qui redirigent vers des sites web malveillants ou des pages de connexion
factices destinées à voler des informations d'identification.
Demande urgente : Le message utilise un langage incitant à l'action immédiate,
comme une menace de désactivation du compte ou la nécessité de vérifier des
informations personnelles rapidement.
Fautes de grammaire ou d'orthographe : Souvent, ces courriels contiennent des
erreurs qui ne seraient pas présentes dans une communication officielle d'une
entreprise professionnelle.
Contenu générique : Le message peut s'adresser au destinataire de manière vague,
comme "Cher membre" ou "Cher parrain", sans utiliser le nom réel de la personne,
indiquant une approche de masse plutôt qu'une communication personnalisée
Question C.2 : Infractions possibles
Citer deux infractions qui peuvent être retenues contre la personne
malveillante
Dans le contexte de la plainte de M. Edwin et de la société Lama Zoo contre la
campagne d'hameçonnage, deux infractions principales peuvent être retenues :
Escroquerie et/ou fraude informatique : Utiliser des courriels d'hameçonnage pour
induire en erreur et voler des informations personnelles ou financières peut être
considéré comme une forme d'escroquerie. Les attaquants utilisent la tromperie pour
amener les victimes à révéler volontairement des informations sensibles ou à
effectuer des actions qui leur sont préjudiciables.
Accès et maintien frauduleux dans un système informatique : Si l'attaquant a
utilisé les informations obtenues par hameçonnage pour accéder illégalement aux
comptes des utilisateurs, cette action peut être considérée comme un accès non
autorisé à un système informatique. Le maintien dans ce système, pour collecter
davantage d'informations ou pour commettre d'autres actes malveillants, renforce la
gravité de l'infraction.
Ces infractions sont sévèrement punies dans de nombreux pays et peuvent donner
lieu à des poursuites judiciaires contre les auteurs de l'attaque d'hameçonnage,
menant à des sanctions pénales, y compris des amendes et des peines
d'emprisonnement.
Question C.3 : Protection contre les attaques CSRF avec CodeIgniter
a) Indiquer pour chacune des deux solutions de protection contre les attaques
CSRF proposées par l’environnement de développement CodeIgniter les
éléments de sécurisation stockés côté client et ceux stockés côté serveur.
CodeIgniter propose principalement deux solutions pour se protéger contre les
attaques CSRF :
• Token CSRF basé sur la session (Synchronizer Token Pattern) :
Côté client : Un jeton CSRF (token) unique est généré par le serveur et envoyé au
client. Ce token est habituellement placé dans un champ caché des formulaires ou
ajouté à l'URL pour les requêtes GET.
Côté serveur : Le token est stocké dans la session de l'utilisateur. Lorsqu'une
requête est reçue, le serveur compare le token envoyé avec la requête à celui stocké
dans la session. Si les deux tokens correspondent, la requête est considérée comme
légitime.

• Double Submit Cookie :

Côté client : Le token CSRF est stocké dans un cookie et également transmis
comme une partie de la requête (souvent dans un champ de formulaire ou dans
l'URL).
Côté serveur : Bien que ce mécanisme repose principalement sur la vérification
côté client, le serveur doit vérifier que le token reçu dans la requête correspond au
token stocké dans le cookie du client.
b) Indiquer les modifications à apporter aux classes Security et Filters afin
d’activer la protection CSRF basée sur la session (Synchronizer token) et
préciser ce que les développeurs des vues devront utiliser dans les formulaires
qu'ils veulent protéger.
Pour activer la protection CSRF basée sur la session dans CodeIgniter, effectuez les
modifications suivantes :
Dans la classe Security : Assurez-vous que la génération et la vérification des
tokens CSRF sont intégrées. CodeIgniter gère cela automatiquement si la protection
CSRF est activée dans la configuration.
Dans la classe Filters : Activez le filtre CSRF pour qu'il soit appliqué globalement ou
spécifiquement aux routes nécessitant une protection. Cela peut être configuré dans
le fichier App/Config/Filters.php.
Pour les développeurs de vues : Chaque formulaire doit inclure un champ caché
avec le token CSRF généré. Avec CodeIgniter, cela peut être fait en utilisant la
fonction intégrée csrf_field(), qui génère automatiquement le champ de formulaire
nécessaire.
Question C.4 : Interface API et Liste Blanche
a) Expliquer pourquoi les routes de l'interface API ne répondent plus depuis la
mise en place de la protection contre les attaques CSRF.
Les routes de l'interface API ne répondent plus depuis la mise en place de la
protection CSRF parce que chaque requête à l'API est maintenant soumise à une
vérification de token CSRF. Comme les requêtes API, en particulier celles en lecture
seule, n'incluent généralement pas de token CSRF (surtout si elles sont appelées
depuis des clients non web comme des applications mobiles ou des services
externes), ces requêtes échouent.
b) Indiquer les modifications à apporter à la classe Filters afin de mettre en
place une liste blanche en vous aidant du fichier de configuration des routes
Pour permettre à certaines routes, comme celles de l'API, d'échapper au filtre CSRF,
vous devez modifier le fichier de configuration des filtres pour y ajouter une liste
blanche. Voici comment procéder :
• Ouvrez le fichier App/Config/Filters.php.
• Trouvez ou ajoutez la configuration pour le filtre CSRF. Vous aurez quelque
chose comme ceci :
public $filters = [
'csrf' => [
'before' => [
'except' => ['/ws/*']
]
], // autres filtres...
];
• Dans la section except, ajoutez les motifs de route pour lesquels vous ne
voulez pas appliquer le filtre CSRF. Dans cet exemple, toutes les routes
commençant par /ws/ seront exclues de la vérification CSRF.
Ces modifications permettent aux routes spécifiées dans la liste blanche de
fonctionner sans vérification CSRF, répondant ainsi aux besoins de Mme Erben et
garantissant que l'API reste accessible pour des requêtes publiques et en lecture
seule
Question C.5 :
Écrire toutes les requêtes à effectuer sur la base de données afin de prendre en
compte la demande de Mme Delperouze
Mise en œuvre des changements dans la base de données
Pour répondre à la demande de Mme Delperouze, nous devons effectuer plusieurs
étapes sur la base de données, incluant la modification des droits du compte
site_public, la création d'une vue SQL vueAnimal, et l'attribution de droits en lecture
seule sur cette vue au compte site_public. Voici les requêtes SQL nécessaires :

• Retirer les droits actuels du compte site_public :

REVOKE ALL PRIVILEGES ON BdAnimaux.* FROM 'site_public';

• Créer la vue SQL vueAnimal :

Supposons que les informations générales nécessaires sur les animaux parrainés
incluent le nom, l'espèce, et une photo. La vue pourrait ressembler à cela (ajustez
selon les noms réels des colonnes et de la table dans votre base de données) :
CREATE VIEW vueAnimal AS
SELECT nom, espece, photo
FROM Animaux
WHERE estParraine = 1;

Cette vue filtre les informations pour n'inclure que les animaux qui sont actuellement
parrainés (estParraine = 1 suppose que chaque animal parrainé est marqué comme
tel dans la base de données).

• Attribuer au compte site_public un droit en lecture seule sur la vue

vueAnimal

GRANT SELECT ON vueAnimal TO 'site_public';

Ces requêtes assument une configuration standard de la gestion des droits dans une
base de données SQL. Selon le système de gestion de base de données spécifique
(MySQL, PostgreSQL, etc.), des modifications mineures pourraient être nécessaires.
Question C.6 : Proposition pour un tableau d'honneur pseudonymisé
Proposer une nouvelle version du tableau d'honneur
Pour répondre aux préoccupations relatives à la divulgation de données
personnelles tout en permettant à chaque parrain de se reconnaître, on peut
pseudonymiser les données en utilisant des identifiants ou des pseudonymes
uniques pour chaque parrain. Voici un exemple de comment cela pourrait être
présenté :

Rang Pseudonyme Nombre d'Animaux Parrainés

1 StarParrain1 12
 2 NatureAmi2 10
3 Defender3 9
10 EcoGuardian10 5

Suggestions pour la mise en œuvre :

Générer un pseudonyme unique : Chaque parrain se voit attribuer un pseudonyme
unique qui n'est pas directement lié à ses données personnelles. Ce pseudonyme
pourrait être généré automatiquement ou choisi par le parrain lui-même lors de
l'inscription ou la configuration de son profil.
Utiliser un identifiant unique non séquentiel : Pour renforcer la pseudonymisation,
chaque parrain pourrait être associé à un identifiant unique (par exemple, un UUID)
qui n'indique pas le nombre de parrains ou leur ordre d'inscription.
Communication sécurisée des pseudonymes : Assurez-vous que chaque parrain
connaisse son pseudonyme par le biais d'une communication sécurisée (compte
utilisateur sur le site, e-mail crypté, etc.) pour qu'il puisse se reconnaître dans le
tableau.
Cette approche permet de célébrer les contributions des parrains sans
compromettre leur vie privée, répondant ainsi aux exigences de sécurité et de
confidentialité tout en maintenant l'engagement de la communauté.