Cas Yak bts sio corigé

A1.1 Bien que la méthode actuelle ne souffre d'aucune erreur de nommage, il serait
avantageux de la renommer en 'vérifierAncienMdp' afin d'améliorer sa clarté.

A1.2:
Cette méthode a pour objectif de vérifier si le mot de passe fourni correspond à l'ancien mot
de passe de l'utilisateur. Son usage revêt une importance capitale pour s'assurer que le
nouveau mot de passe diffère de l'ancien, en conformité avec la politique de sécurité des mots
de passe.

A2.1:
Il est préconisé de demander des mots de passe d'au moins 12 caractères, contenant au
minimum une majuscule, une minuscule, un chiffre et un caractère spécial lors de
l'authentification des utilisateurs.
A2.2:
public boolean modifierMdp(String nouveauMdp) {
if (!this.motDePasse.equals(nouveauMdp)) {
this.motDePasse = nouveauMdp;
System.out.println("Le mot de passe a été modifié avec succès.");
return true;
} else {
System.out.println("Le nouveau mot de passe doit être différent de l'actuel.");
return false;
}
}

A3.1:
@BeforeEach
void setUp() {
utilisateur = new Utilisateur("motDePasse123");
}
@Test
void verifModifierMdp() {
assertTrue(utilisateur.modifierMdp("nouveauMotDePasse123"));
assertFalse(utilisateur.modifierMdp("nouveauMotDePasse123"));
}

A3.2:
Pour l'application Breizh-SN, la possibilité pour un employé d'accéder à des sections sensibles
telles que la gestion financière pourrait avoir des conséquences graves, telles que la perte de
confiance des clients, des pertes financières et des problèmes juridiques. Afin de prévenir ces
risques, il est essentiel de mettre en œuvre une gestion des autorisations qui limite l'accès aux
données en fonction des rôles des utilisateurs.
B1.1:
Pour ajouter un champ à la table client, il faut faire la requête suivante :
ALTER TABLE Client
ADD accordPubli BOOLEAN DEFAULT FALSE;

B1.3:
Bonjour,

Nous vous informons d'une option de consentement pour recevoir des communications
améliorées de notre part via le publipostage. Aucune action n'est nécessaire si vous ne
souhaitez pas y participer ; par défaut, vous ne serez pas inscrit.

Si vous souhaitez consentir et recevoir des offres personnalisées, veuillez visiter

https://www.EchapBox.com/accordPubli dans le mois suivant.

Nous accordons une grande importance à votre vie privée et vous pouvez retirer votre
consentement à tout moment.
Merci pour votre confiance,
L'équipe EchapBox

B1.4:
Pour être en conformité avec le RGPD et assurer l'intégrité des enregistrements de
consentement, plusieurs mesures doivent être prises :
- Obtention d'un consentement explicite par le biais d'un formulaire sur le site, sans pré-
cocher de case.
- Documentation des détails du consentement dans une base de données sécurisée.
- Application d'horodatages et de signatures numériques aux enregistrements de
consentement, avec éventuellement l'utilisation de la blockchain pour garantir l'immuabilité
des données.
- Fourniture aux utilisateurs d'une interface pour gérer leur consentement et explication de la
procédure de révocation.
- Réalisation d'audits réguliers pour assurer la conformité et mise à jour de la politique de
confidentialité en conséquence.

B1.5:
La structure proposée pour la nouvelle table ClientAnonyme est :
ClientAnonyme(
id INT AUTO_INCREMENT,
genre VARCHAR(20),
trancheAge VARCHAR(20),
departement VARCHAR(3),
PRIMARY KEY (id)
)

B2.1:
Les risques R1 et R2 présentent une gravité élevée pour l'entreprise en raison de leurs impacts
potentiels sur les finances, la réputation et la conformité légale :
- R1 (Injection SQL avec acompte supérieur au prix du contrat) : Ils comportent des risques
financiers, réputationnels et de conformité liés à la fraude financière.
- R2 (Injection SQL avec montant inférieur au minimum) : Ils engendrent des risques
financiers, réputationnels et de conformité liés à l'intégrité des transactions.
Ces risques justifient un niveau de gravité élevé en raison de leurs conséquences potentielles
sur l'entreprise, mettant particulièrement l'accent sur les aspects financiers et la réputation.
B2.2:

SELECT Clients.id, Clients.nom, Clients.prenom

FROM Clients
JOIN Contrats ON Clients.id = Contrats.client_id
WHERE Contrats.acompte_versé >= Contrats.montant_à_payer;
```

C1.1:
Pour se prémunir contre les attaques CSRF, il est nécessaire de recourir à l'utilisation de
jetons CSRF uniques, en suivant ces étapes :
- Génération : Le serveur génère un jeton CSRF unique lié à la session de l'utilisateur lors de
sa connexion.
- Inclusion : Ce jeton est intégré dans chaque formulaire et requête AJAX envoyés par le
navigateur de l'utilisateur au serveur.
- Vérification : Le serveur s'assure que le jeton CSRF fourni avec la requête correspond
effectivement à celui stocké dans la session de l'utilisateur.
C2.1:
a) Dans un extrait du fichier journal de l'application "Désir d'Ailleurs" daté du 10/05/2023,
plusieurs événements ont été enregistrés :
- AllanG a fait face à une erreur de connexion.
- Une tentative de connexion avec des champs vides a été repérée.
- RichardP a rencontré une erreur de connexion, enregistrée cinq fois à la même seconde.
- AllanG s'est connecté avec succès.
- RichardP continue de rencontrer des erreurs de connexion, signalées trois fois de plus à la
même seconde.
b) Le fait le plus remarquable réside dans les erreurs de connexion répétées rencontrées par
RichardP, ce qui suggère un problème persistant, soit du côté de l'utilisateur soit du côté
technique, demandant une attention spécifique.
C2.2:
a) Pour répondre à cette exigence et améliorer la gestion des connexions, il est possible
d'ajouter une nouvelle table afin d'enregistrer les tentatives de connexion ainsi que leur
résultat :
TentativesConnexion(
idTentative INT AUTO_INCREMENT,
idCli INT,
timestampConnexion DATETIME,
resultat ENUM('Réussite', 'Échec'),
PRIMARY KEY (idTentative),
)

b) Deux entrées démontrant une tentative de connexion effectuée par un seul utilisateur :
Premier : [21:41:24] NOTICE: utilisateur RichardP : erreur de connexion
Deuxième : [21:41:26] NOTICE: utilisateur RichardP : erreur de connexion

C2.3:
Pour désactiver un compte utilisateur, il est envisageable d'ajouter un champ "etatCompte" à
la table Client, spécifiant si le compte est actif ou désactivé. Il serait alors nécessaire de mettre
à jour l'état du compte concerné en le marquant comme "désactivé" afin d'empêcher la
connexion lorsque le compte est désactivé.