Révisions - Sécurité applicative

DUVERGER Kévin
14 février 2024

Table des matières

1 Cours sur le social engineering : 3

1.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Pourquoi ça marche : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Le cycle et les vecteurs d’attaques : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Conclusion et contremesures : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Cours sur les mails et la PKI : 5

2.1 Introduction : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Les mails : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 La PKI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Cours du 06/10/2023 - PKI, API et Cloud - Virginie Harriet : 7

3.1 La PKI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Les API (Application Programme Interface) : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Le cloud : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Cours du 20/10/2023 - RGPD - Caroline Boyer-Capelle : 10

5 Cours du 25/01/2024 - Pentest Web - Aloyse Ndong : 13

5.1 L’intervenant : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Présentation de l’audit : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3 Présentation de l’audit appliqué aux applications web : . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Méthodologie d’audit appliquée aux applications web : . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5 Un peu de TP : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6 Cours du 01/02/2024 - Vote - Sylvain Ruhault : 18

6.1 Vote électronique : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1
DUVERGER Kévin Révisions - Sécu. app Université de Limoges

1 Cours sur le social engineering :

1.1 Introduction :
”Tout l’art de la guerre est basé sur la duperie” - L’art de la Guerre - -400 - Sun-Tzu.
”On est inclinés à croire ce qu’on ne connaı̂t pas car il ne nous ont jamais déçu” - Samuel Johnson.

Définition : l’ingénierie sociale regroupe tous les moyens où quelqu’un essaie de manipuler une personne pour ac-
complier une action qui peut être ou ne pas être dans l’intéret de la cible : révéler des informations confidentielles,
créer / suspendre un accès, c’est souvent couplé à des techniques d’OSINT (OpenSource INTelligence).
OSINT peut se faire via internet (site web de l’entreprise, réseaux sociaux, données publiques, infos sur les DNS,
archives web) ou encore avec les lettres d’informations, les journaux, les paternaires, les fusions, ... SIGINT : Signals
Intelligence : scan de réseaux wifi, SMS, tracking GPS. HUMINT (Human Intelligence) : social engineering, c’est le
moyen le plus simple pour accéder à l’information.

Plus une entreprise a de salariés, plus il y a de maillons faibles potentiels : il est difficile de s’en protéger (il faut
éduquer les gens et continuer les entraı̂ner à déceler et résister aux techniques). Les attaquants utilisent des méthodes
qui ne relèvent pas uniquement de la technique (manipuer les gens au lieu de machines c’est plus simples, ils profitent
des réponses prévisibles des triggers psychologiques humains).
La collecte d’information peut être directe (interactions avec la cible) : soit par le téléphone, soit en personne, soit
en ligne ou encore avec des arnaques au président. Il est également possible de faire des observations indirectes / des
inférences.

1.2 Pourquoi ça marche :

La bonne question à se poser est quel est le plus grand risque de sécurité pour mon entreprise ? En 2004, Gartner a
annoncé que le plus grand risque pour les grosses entreprises serait des attaques de social enginnering de plus en plus
sophistiquées pour contourner les défenses IT. En 2019 le FBI a indiqué que c’était la plus grande source de pertes de
revenu pour les entreprises devant les Zero-Day.
Les attaques par SE sont menées par des pirtaes / cyber-criminels / escrocs / espions missionnés par des entreprises
concurrentes / agents de puissances étrangères / terroristes / des employés mécontents. Ils cherchent nos informations
(voire des données compromettantes), nos secrets commerciaux, notre argent et nos ressources IT.
Toujours garder à l’esprit qu’il est plus facile de contourner un humain que de multiples défenses techniques parce que
ça marche. Pour ne pas se faire avoir il faut approcher les problèmes de façon rationnelle, ignorer les informations non
importantes, estimer l’importance d’une information, garder l’esprit ouvert et résister à la tendance naturelle pour les
biais.
Expérience du photocopier : ”Puis-je vous passer devant pour faire une copie ?” (réussit 62% du temps), ”Puis-je vous
passer devant pour faire une copie car je suis pressé ?” (réussi 94% du temps) : l’existence d’une raison suffit.

Les biais :
ˆ Le biais de réciprocité : nous retournons une faveur peu importe celle initiale (même si nous ne la désirions
pas). Souvent utilisé par les charités, exploite la tentation de donner en retour. En SE permet de lancer des
demandes compliquées : ”pour enlever les virus de votre ordinateur, j’aurais besoin de vos identifiants”.
ˆ La consistance : on essaye de rester cohérent avec nos actions pasées même si les raisons ont changé depuis.
C’est exploité par les vendeurs : on commence à remplir un formulaire sans engaement ce qui nous fait donner
beaucoup d’informations personnelles, le cerveau se commit et décide de rester concistant et ce même si le
message change.
ˆ La preuve sociale : on essaie de faire et de pense ce que les autres personnes qui nous ressemblent font et pensent
(fonctionne même quand les gens en sont conscients). Applications en SE : ”Bob m’a donné son mot de passe
et vous ?”.
ˆ L’appréciation / similarité : on coopère plus facilement avec les gens qui semblent nous apprécier (principe du
good cop / bad cop). La flatterie marche, même si elle est mauvaise. Même genre de réaction si on se trouve
des points communs.
ˆ L’autorité : on coopère avec une personne qui semble être en charge (parfois sans se poser questions trop
littéralement avec l’expérience de Milrgram), effet blouse blanche / uniforme / badges, cela fonctionn très bien
dans les structures de type militaire.
ˆ La pénurie : on surévalue l’apparente rate d’informations : célélbrations, censure, ”Act now ! Supplies are
limited !”, cela peut être utilisé pour gagner un accès (je suis là jusqu’à midi donc si j’ai pas les accès vous
devrez attendre un mois de plus, bonne chance pour y expliquer à votre posse) ou pour une augmentation (vous
savez, la boite ... m’a contacté récédemment pour un job).

2 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

1.3 Le cycle et les vecteurs d’attaques :

Le cycle d’attaque : récupération d’informations, établissement de la confiance, exploitation de la confiance et utilisa-
tion de ces informatiokns. ”How do you eat an elephant, one bite at a time !”
On peut utiliser le téléphone (vishing) : faible risque et forte récompense, peut être utilisé de n’importe où sur le globe,
il est simple de masquer son identité, c’est difficile à prévenir et ça permet de toucher les bonnes personnes rapidement
si on connaı̂t la structure de l’entreprise cible. Pour l’exploiter : trouver le maillon faible, récupérer des infos, établir
/ réactiver une relation.
Une autre possibilité est en personnne : on rentre dans les locaux et on interagit avec le personnel, on demande soudoie
ou effraie pour obtenir de l’information. Cela permtet d’obtenir beaucoup d’informations mais avec un vrai rissque
de se faire arrêter / identifier. Les techniques : surveillance (donne des infos clés sur l’organisation du bâtiment par
exemple, permet de placer du matériel de surveillance), du piggybacking / tailgating (suivre une personne autorisée),
shoulder surfing (regarder au dessus de l’épaule), de l’eavesdropping, des périphériques USB piégés involontairement
oubliés dans un endroit où ils seront trouvés, récupérer le contenu de poubelles (des informations sont jetées sans être
broyées, qui surveille ses poubelles) on peut y trouver régulièremetn des listings téléphoniques / des organigammes /
des numéros de compte / des identifiants.
On peut également faire du phishing avec peu de risque et en faire une version distribuée (spear phishing).
ET finalement on a le reverse social engineering ou c’est la cible qui va contacter l’attaquant : fichier supprimés,
pop-ups, sentiment d’urgence.

1.4 Conclusion et contremesures :

Tout le modne peut être la cible, les attaquants vont choiisr le risque minimum, ils exploitent les faiblesses humaines
et ces informations vont permettre de s’approcher du but : la solution n’est pas technologique.
Ce qu’on peut penser et qui est une erreur : les attaques de SE qui fonctionnent demandent de grandes compétences,
elles demandent du matériel de pointe, nos protocoles de sécurité sont suffisants, seuls des gens crédules peuvent se
faire avoir. Il ne faut pas les traiter comme un problème indépendant.
La réalité c’est que la plus grande vulnérabilité d’une entreprise ce sont les gens (et pas seulement les extérieurs mais
ausi les employés peu importe leur position hiérarchiques).
Quelques contremesures : mettre en place des standards et des guidelines pour contre le SE dans les organisations, les
employés suivront s’ils comprenent pourquoi ils font ça. Politique : confronter les extérieurs, rappel systématique, pas
de piggybacking / tailgating, procédures pour le help desk. Identifier les zones vulnérables : les mots de passe doivent
rester personnels et sécuriser toutes les entrées. Entraı̂nement / formation : tout le monde peut être une cible, pour
minimiser les chances de succès il faut entraı̂ner le personnel (via par exemple des jeux de rôle en interne).
Au final il faut tester régulièrement sa résistance au SE, inclure du SE dans les audits de sécurité et les résultats
doivent être tenus confidentiels.

3 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

2 Cours sur les mails et la PKI :

2.1 Introduction :
Les attaques et les vulnérabilités vont principalement concerner : les en-têtes, les protocoles, la phase d’authentification
ou encore le traffic (DoS, sniffing). Certaines attaques sont communes mais la majorité ne visent qu’une application.
Le premier type d’attaque que l’on voit souvent est les attaques sur les en-têtes : la plupart des applications ont des
en-têtes libres qui doivent être parsés correctement, on peut les utiliser pour causer des buffer overflow.
Les attaques protocolaires sont spécifiques à une application.
Les attaques d’authentification sont plus répandues et peuvent être de 2 types : directe où l’on se sert de l’application
pour déterminer un mot de passe, indirecte dans laquelle on va essayer de contourner le mécanisme d’authentification.

2.2 Les mails :

Un système de mail électronique définit 4 fonctions : la création (utilisateur créée et édite un message), l’envoi où l’uti-
lisateur spécifie un ou des destinataires et le protocole se charge d’y envoyer aux bonnes boı̂tes aux lettres, réception (le
destinataire peut demander au serveur de mail d’accéder et de lire ses mails), stockage (l’expéditeur et le destinataire
peuvent conserver une copie).
MUA (Mail User Agent) pour transférer un mail sur le serveur d’émission. MTA (Mail Transfer Agent) pour envoyer
le message à la bas ede données du destinaire. MDA (Mail Delivery Agent).

SMTP (Simple Mail Transfer Protocol) : standard pour transmettre des mails défini dans la RFC 821. Il ne définit ni
le format ni le contenu des messages sauf qu’ils doivent être en ASCII et qu’il ajoute des informations sur le chemin
parcouru. Le protocole essaie d’être fiable mais il ne prévoit rien (les hôtes perdents les fichiers, l’un des deux ne donne
pas d’accusé de réception, ...). Il ne comporte que 14 commandes simples (ex : HELO pour le premier message, MAIL
FROM, RCPT TO, Quit).
Les attaques sur les en-têtes sont peu fréquentes à l’heure actuelle mais peuvent toujours arriver sur de vieilles
implémentations pour faire des buffer overflow. De plus les attaques protocolaires sont plutôt difficiles à mettre en
place sur des protocoles challenge / response (les commandes reçues dans le désordre sont ignorées) du coup on va
plutôt viser des connexions multiples pour faire un DOS sur le serveur.
Les attaques les plus fréquentes pour SMTP sont les attaques par authentification car il n’y a pas authenfication du
client (ce qui entraı̂ne de nombreux problèmes de spam et de phishing). Les attaques basées sur le traffic sont aussi nom-
breuses : on va utiliser reply to pour faire du déni de service distributé, des messages trop gros vont ralentir les serveurs.

POP (Post Office Protocol) : c’est un protocol de transfert de mails entre un client et un serveur (RFC 1939) qui
fournit également un mécanisme d’authentification. Dans une session POP : le client POP3 se connecte à un serveur
POP3 (login et mdp en clair), l’utilisateur peut configurer àquelle fréquence les mails sont vérifiés et donc combien de
fois le mot de passe est transmis.

IMAP (Internet Mail Access Protocol) : permet de récupérer et classer les messages, POP ne fonctionne pas très
bien avec plusieurs clients vu que les mails sont supprimés une fois lus (avec IMAP on peut les garder sur le serveur
et propager les modifications entre les clients).

Contremesures : STARTLS : permet de faire en sorte que SMTP utilise TLS.

SMTP-Auth : extension qui permet à l’utilisateur de s’authentifier (RFC4954).
Filtrage d’emails / de contenu ou encore forensics des emails.
SPF (Sender Policy Framework) : processus d’authentification qui permet de vérifier la conformité de l’expéditeur
d’un mail, il indique qui a le droit d’utiliser notre nom de domaine en listant les IPs destinées à envoyer des mails,
évalue l’identtié fournie par le MAIL FROM.
DKIM (DomainKeys Identified Mail) : permt d’authentifier de manière fiable le nom de domain de l’émetteur d’un
mail, repose sur des signatures électroniques des messages et d’une partie des en-têtes. Il permet d’assurer 3 choses :
le contenu du mail n’a pas été modifié, les en-têtes du mail n’ont pas changé pendant l’envoi, l’expéditeur possède le
domain DKIM correspondant ou est autorisé par le propriétaire.
DMARC (Domain-based Message Authentication, Reporting and Conformance) : il a pour objectif de standardiser la
manière d’utiliser SPF et DKIM par les MTA, il permet de faire de la surveillance et de l’authentification, les politiques
sont publiées dans le DNS public du domaine comme enregistrements TT.

2.3 La PKI :
Le problème de l’échange de clés publiques : dans une architecture publique la prise en compte d’une clé publique
nécessite d’avoir confiance en la personne qui nous la fournit. Cette dernière peut s’obtenir soit par envoi point à point
(GPG) soit en passant par un annuaire centralisé comme LDAP. Dans les 2 cas il faut s’assurer que la clé obtenue
provient bien de la bonne personne concernée (pas de garanties !). On pourrait très bien imaginer un adversaire qui

4 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

fasse un man in the middle pour remplacer cette clé par la sienne.
L’objectif de la PKI va être de fournir des tiers de confiance partagés par Alice et Bob. Une PKI va être composée de
plusieurs éléments : des certiifcat électroniques, des autorités pour l’enregistrement (RA) / la certification (CA) / la
validation (VA) ainsi qu’un protocole standardisé de vérification.
Le certificat joue le rôle d’une carte d’identité numérique de la clé publique. Il contient l’identité de la personne, sa
clé publique et une attestation de cette association par un tiers de confiance. L’attestation est en fait la signature
électronique apposée par l’autorité de certification.
La clé publique de l’autorité est ensuite largement diffusée et peut également être signée par une autre autorité : on
parle alors de chaı̂n ede confiance. La confiance est accordée si dans la chaı̂ne on trouve une autorité dans laquelle on
a confiance (ex : VeriSign, Certinomis, ...). La confiance dans la PKI repose donc sur la confiance que l’on accorde aux
autorités associées.
Par défaut les OS et les navigateurs disposent de clés publiques d’autorités de confiance. Sous windows on peut utiliser
le service certmgr.msc pour voir ces certificats.
Un certificat est doté d’une date d’expiration : si l’aurotié disparaı̂t entre temps les certificats associés doivenet être
révoqués. La CA doit donc délivrer des certificats, leur donner une date de validité et les révoquer si sa clé privée est
compromise.
Il y a 3 classes de certificats :
ˆ Les certificats de classe 1 qui associent une clé publique à un e-mail (c’est juste le mail qui est contrôlé), permet
de la signature et du chiffrement de courrier électronique, ils peuvent s’obtenir très rapidement et souvent
gratuitement.
ˆ Les certificats de classe 2 font une vérification plus poussée de l’identité pouvant aller jusqu’à la présentation
physique, ils permettent de faire de l signature d’application logicielle par exemple.
ˆ Les certificats de classe 3 vont avoir le plus haut niveau de vérification avec une compensation financière en
cas de litige, il permettent également de mettre en oeuvre sa propre CA pour émettre des certificats (l’entité
devient alors une LRA : Local Registration Authority).
Une CA reconnue doit être plus qu’un simple logiciel : il faut des moyens humains pour vérifier les informations et elle
doit fournir des CPS (Certification Practice Statement) qui donne la manière dont les infos sont vérifiées, les étapes
pour produit le certificat et comment révoquer ces derniers.
Obtention d’un certificat : on s’enregistre auprès de la RA qui va générer une paire de clés, l’envoyer à la CA qui va
pour finir nous envoyer notre certificat. Ce dernire pourra ensuite être stocké localement dans un ”Key Store” (base
de données locale accessible via une API) (par exemple PKCS#11, CAPI, JCA, ...) ou encore dans un annuaire LDAP
pour un réseau local.
Le format des certificats est défini par l’IETF à travers le standard X.509. Il utilise actuellement la version 3 des
certificats : issuer caractérise la CA, subject le propriétaire du certificat et la gestion des extensions. Les noms sont
représentés grâce au DN de X.500.
Les certificats peuvent aussi identifier une CA / des CA intermédiaires / des matériels / des utilisateurs / des appli-
cations.
La validation d’un certificat : le contenu (sauf la signature) est passé dans l’algorithme de Hash ce qui donne une valeur
A, ensuite la signature est vérifiée avec ce hash et la clé publique de l’autorité. Ensuite il faut faire ça pour toute la
chaı̂ne de confiance. Il faut également vérifier que le certificat n’a pas expiré et n’a pas été révoqué en consultant la
CRL (Certificate Revocation List) de la CA.
Les CRLs sont des listes noires de certificats : 0 = non-spécifié, 1 = toutes les clés compromises, 2 = la CA compromise,
3 = changement d’affiliation du certificat, ...
La clé privée doit rester la propriété exclusive de son propriétaire : elle ne doit jamais être communiquée ni copiée, elle
doit être stockée en étant chiffrée par un algorithme symétrique et la paire de clé doit avoir une durée de vie et pouvoir
être révoqué. Mais que fait quand l’utilisatuer perd sa clé ? que sa hiérarchie doit avoir accès à certains documents ?
en cas de décision de justice ordonnant la divulgation de certaines données ?
Pour ce faire on utilisera une autorité de séquestre (key escrow) : elle va se charger de stocker les infos secrètes comme
les bi-clés. C’est un élément très important d’une PKI car il doit absolument maintenir la confidentalité des données.
Un moyen pour simplifier l’utilisation d’une autorité de séquestre est d’utiliser plusieurs couples de clés (un couple
sert pour le chiffrement et un autre pour la signature).
Les limites de la PKI : la révocation des certificats n’est pas optimale (listes noires à réactualiser sans celle, mieux =
listes blanches), tout repose sur la chaı̂n de confiance (si les CA compromises le système flanche), les CA sont toutes
des entreprises privées qui se financent sur l’émission de certificat et pas sur les vérification : que se passe-t-il en cas
de faillite / d’acquisition ?

5 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

3 Cours du 06/10/2023 - PKI, API et Cloud - Virginie Harriet :

3.1 La PKI :
Une fonction de hachage c’est une fonction mathématique à sens unique dont la sortie sera pseudo-aléatoire et de
longueur fixe. Elle peut être utilisée pour détecter l’altération des données et doit éviter au maximum les collisions.
MD5 et SHA1 sont de mauvaises fonctions de hachage avec les standards d’aujourd’hui, on préférera SHA2 et SHA3
(recommandé par l’ANSSI).
Chiffrement symétrique : on chiffre et déchiffre avec la même clé (DES c’est nul, utiliser AES recommandé par l’ANSSI).
Chiffrement asymétrique : on chiffre avec une clé et on déchiffre avec une autre, utiliser RSA 2048 au minimum et
ECC-256 (recommandations de l’ANSSI).
La bi-clé va contenir la pair clé privée / clé publique, on peut l’utiliser pour chiffrer, signer et s’authentifier.

Confidentialité : un message chiffré avec la clé publique d’Alice ne peut être déchiffré que par la clé privée d’Alice.
Intégrité et non-répudation : signature (on utilise la clé privée pour la signature).
Authentification : se fera en mode challenge response (le serveur va envoyer une valeur chiffrée avec notre clé publique
et on devra renvoyer le déchiffré ce qui prouvera qu’on connaı̂t la clé secrète).

PKI = ICG (Infrastructure de gestion de clés).

Comment distribuer la clé publique d’Alice de manière sûre à tous les interlocuteurs ?
Un certificat c’est un passerport électronique : contient le nom de celui qui l’a émis, la période de validité, l’identité
d’Alice ainsi que sa clé publique. Tout le monde peut avoir accès à ce certificat et il ne contient pas la clé privée.
L’autorité de ceritifcation va produire des certificats. Lors de leur vérification on s’assure qu’ils ont été émis par une
CA à laquelle on fait confiance, qu’ils sont toujours valides et pas révoqués. L’autorité de certification s’assure de
l’identité de la personne lors de l’émission du certificat, gère sa révocation.
Un certificat peut être utilisé pour garantir : la non-répudiation, l’intégrité, la confidentialité et l’authentification.
On peut ensuite utiliser ces certificats dans TLS : soit on utilise pas TLS et les données passent en clair, soit si on
l’utilise il y a obligatoirement authentification du serveur et on peut optionnellement demander une authentification
du client.

PKI = IGC = ICP. Son univers est un ensemble de composants physiques, logiciels et procédures.
Le but est de fournir des garanties qui permettent de faire confiance à un certificat signé par une CA. Ses services :
enrgistrement des utilisateurs, génération de certificats, renouvellement, révocation, publication de ces derniers, public
des listes de révocation, identification et authentification des utilisateurs, archivage, séquestre et recouvrement des
certificat.
4 autorités dans une PKI : certification, enregistrement, validation, séquestre.
Cas d’usage : accès sécurisé à votre banque en ligne via SSL/TLS, le certificat va permettre de vérifier que c’est bien
le serveur de la banque auquel on se connecte mais également d’échanger la clé de sesion symétrique.
OCSP : Online Certificaet Signing Protocol : permet de savoir si le certificat (identifié par son numéro de éérie) est
révoqué ou non.
La PKI de l’état français est l’IGCA.

Key Ceremony :
La première étape est l’initialisation du HSM + la création de la CSR et du bi-clé.
La seconde étape : signature du certificat auto-signé.
La dernière étape : initialisation de la PKI.
Cette cérémonie fait intervenir plusieurs personnes : le master, le key manager, le security officer, l’auditeur, les 5
secrets de shamir et 2 témoins. L’idée est qu’il n’y aura besoin que de 3 secrets pour que ça marche (allez voir le cours
de meca-crypto).

On peut utiliser les certificats pour s’authentifier : exemple de FIDO.

FIDO2 permet de faire de l’authentification avec un bi-clé propre à chaque service.
Il utilise une méthodologie ”challenge -response”.
L’avantage est qu’il n’y a pas besoin de mot de passe et qu’il peut faire du multifacteur, il est sécurisé contre les
attaquants actifs qui font un man-in-the middle, il n’y a pas d’information secrète stockée sur le serveur, c’est un
standard ouvert et reconnu.

Pour aller plus loing : chiffrement symétriqu eAES, chiffrement asymétrique RSA, collisions sur les fonctions de ha-
chage, certification des produits par les agences nationales, règlementations associées (Critères Communs et eIDAS),
la norme X.509 pour le certificats, la PKI de l’état français (ICGA), l’horodatage, les HSM = Hardware Seucrity
Module, FIDO 2, France connect, OIDC / OAUTH, SSO, Passwordless.
France connect : moyen de s’authentifier basé sur un ensemble d’IDP (fournisseurs d’identités compatibles avec france
connect)

6 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

3.2 Les API (Application Programme Interface) :

Une interface de programmation est un ensemble normalisé de classe / de méthodes / de fonctions / de constantes
qui sert de façade par laquelle un logiciel offre des services à d’autres logiciels. Elle est offerte par une bibliothèque
logicelle ou un service web, le plus souvent accompagnée d’une description qui spécifie comment des programmes
consommateurs peuvent se servir des fonctionnalités du programme fournisseur. On parle d’API à partir du moent
où une entité chercher à agir avec ou sur un système tiers et que cette interaction se faire de manière normalisée en
respectant les contraintes d’accès définir par le système tiers.
Dans l’industrie logicielle, les programmes se servent de pas mal d’interfaces de programmation car on va préférer
utiliser des briques de fonctionnalités fournies par des logiciels tiers. Cela nécessite de connaı̂tre la manière d’intéragir
avec les autres logiciels qui dépend de leur interface de programmation. Le programmeur n’a pas besoin de connaı̂tre
les détails de la logique interne du logiciel tiers, seule l’API eest réellement nécessaire pour utiliser le système tiers en
question.
Les systèmpes d’exploitation, les SGBD, les langages de programmations, les serveurs d’applications comportement
une ou plusieurs API.

3 règles d’or pour la sécurité des API :

ˆ Authentification : tout accès aux API doit authentifier l’utilisateur et le système appelant.
ˆ Habilitations : les APIs doivent implémenter les principes de moindre privilège via des contrôles : logique
technique (la validation de la signature du jeton) et logique métier (l’utilisateur a-t-il le droit d’accéder à une
ressource).
ˆ Développement sécurisé : l’API doit respecter les bonnes pratiques de développement sécurisé : contrôles des
données entrantes pour se protéger contre les attaques malveillantes, journalisation des évènements techniques
et métiers, pas de données personnelles ou sensibles dans les URLs, ... (TOP 10 OWASP)
RGPD : la gestion des données par les API doit prendre en compte la réglemtantion (identifer et protéger les données,
minimmiser l’utilisation des données, contrôler et tracer l’accès aux données).
Cloisonnement : l’accès aux ressources est conditionné par un mécanisme d’authentification par des règles de routage
et d’exposition des services.
L’authentification peut se faire en OAuth2 ou OIDC.

3.3 Le cloud :
4 principes : tout le temps (Any Time : AT), partout (Any Where : AW), sur tout support (Any Device), tout contenu
(Any content) : ce qui nous donne ATAWADAC.
Il y a de nouveaux enjeux pour les entreprises : les utilisateurs internes / externes sont e plus en plus exigeants (time-
to-market, disponibilité, réactivité, qualité, délivrabilité, agilité des processus, expérience utilisatuer, exploitation de
la data, ...)
Les géants du web GAFAM vont naturellement vers ATAWADAC et les autRES BHATX (Baidu, Huawei, Alibaba,
Tencent, Xiaomi) redéfinissent les modèles économiques du 21ème siècle.
Intérêt du cloud : maintenir et continuer à garder la main sur son activité (nomadisme), on a aussi la scalabilité (on
va mettre les ressources à disposition en fonction de nos besoins).

Cloud computing : modèle informatique permettant un accès réseau omniprésent, pratique et à la demande à un
ensemble partagé de ressources informatiques configurables qui peuvent être rapidement mises à disposition et libérées
avec un minimum d’administration ou d’interaction avec des fournisseurs de service.
5 caractéristiques essentielles : libre-service à la demande, mutualisation des ressources, large accès au réseau (ouver-
ture), élasticité horizontale et vertificale (capacité de stockage et puissance de clacul adaptées au besoin du consom-
mateur), service mesuré = paiement à l’usage.
3 modèles de service : SaaS (mise à disposibiont d’applications entreprise), PaaS (mise à disposition de plateformes
de middleware, de développement, de test, d’exécution d’applications), IaaS (ise à disposition de ressources informa-
tiques).
4 modèles de déploiement : privé (utilisé par un seul organisme = datacenter), hybride (ménage de plusieurs modèles
de cloud pour avoir les avantages des différents environnemnts), communautaire (partagé par plusieurs organismes) et
public (déployé par un fournisseur de cloud tiers et partagé par les utilisateurs).

5 grands fournisseurs de services cloud : Amazon, Microsoft, Google, Alibaba, Oracle. IBM a une position de lea-
der mondial sur les segments de cloud privés et hybrides. Les autres acteurs sont sur des marchés de niche. Les CSP
français proposent généralement de l’IaaS et hébergent du SaaS (OVH, OutScale, Ikoula, Scaleway, ...)

Les technologies du cloud :

HTML5, CSS, Javascript, DevOps (vise à l’amélioration continue), Container (machine virtuelle exécutée dans le
cloud), Microservices (logicels proposés sous forme de container, ils réalisent généralement une seule tâche).

7 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

Les données vont avoir différents niveaux : C1, C2, C3, C4 (C4 on y mettra pas dans le cloud).
Eléments essentiels pour la sécurité du cloud : identité (chaque action doit pouvoir être identifiée), data (les données ne
doivent pas être corrompues / accessibles), devices (les dispositifs d’accès doivent être aussi sécurisés que l’infrastruc-
ture cloud), apps (les applications et leur cadre d’utilisation doivent être vérifiés), infra (l’infrastructure doit vérifier
certains critères nous garantissant la pérennité et la sécurité des données).
Lois et règlements français : CISPE (Cloud Infrastructure Service Providers in Europe), RGPD (Règlement général
sur la protection des données), loi de programmation miliaire, ...

8 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

4 Cours du 20/10/2023 - RGPD - Caroline Boyer-Capelle :

La différence entre le droit et la morale :
Le droit va aboutir à une sanction financière en cas de manquement.
La morale il n’y aura pas d’amende imposée par la puissance publique.
C’est pas juste des bonnes pratiques : si on vient fouiller et ce que c’est pas à fait sanction.
Le RGPD est commun à toute l’union européenne : Règlement général de la proctection des données.
LIL : Loi Informatique et Liberté : date du 6 janvier 1978 et a été modifiée pour devenir le RGPD.
La LIL date du moment où l’usage de l’informatique apparaı̂t : vu qu’on peut croiser les informations, si on récupère
suffisamment de données personelles on peut totalement identifier une personne. SAFARI : système automatisé de
fichiers.

Définition d’une donnée personnelle :

C’est une donnée qui peut avoir un impact sur la sphère privée.
C’est une information liée à des personnes physiques.
Que le prénom tout seul c’est pas forcément de la donnée personnelle (car plein de gens partagent le même prénom)
mais si on rajoute le nom en revanche ça devient une donnée personnelle. Le maı̂tre mot c’est pour permettre d’iden-
tifier une personne.

Comme dit précédemment, le RGPD n’a pas révolutionné la loi Française, il s’est inspiré de la LIL.
L’individu a des roits sur ses données personnelles : décider à contrôler les usages qui en sont fait.
CNIL : autorité créée spécialement pour vérifier que cette loi est respectée.
Cela a aboutit à la mise en place d’obligations déclaratives.

En revanche on ne peut pas faire une loi de la protection des données pour tous les pays du monde : les dicta-
tures n’accepteront pa (Chine, Corée du Nord, Iran) et certaines démocracties n’ont pas la même approche que la
France pour ces données : par exemple les USA veulent la circulation des données pour se faire de l’argent.
24 octobre 1995 : directive européenne (directive : un objectif et c’est aux états membres de faire ce qu’il faut pour
l’atteindre).
27 avril 2016 : règlement UE (après un problème de réseaux sociaux) : le règlement s’applique directement dans tous
les états (c’est le fameux RGPD). D’application au 25 mai 2018 : il faut laisser un peu de temps aux états membres
pour s’adapter. On peut s’y référer pour l’immense majorité des problématiques.
Loi du 20 juin 2018 : c’est une adaptation de la LIL : les gens vont donner leurs données personnelles aux réseaux
sociaux : du coup on a un gros problème.

Revenons sur les données personnelles : une donnée personnelle c’est toute information se rapportant à une per-
sonne physique identifée ou identifiable (on ne protège pas les personnes morales).
Identification directe : une donnée personnelle qui nouspermet d’identifier directement la personne : nom + prénom /
adresse mail / ...
Identification indirecte : on a une donnée pseudonymisée telle que le numéro de sécurité sociale, l’empreinte digitale,
l’adresse IP, le numéro étudiant, le numéro de téléphone et en regroupant suffisamment d’informations on peut iden-
tifier une personne (ex : le fils aı̂né du médecin habitant au 5 rue Jean Jaurès).
Ensuite la définition de ce qu’est un traitement est donnée : c’est toute opération ou tout ensemble d’opérations ef-
fectuées ou non à l’aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère
personnel.
Donnée personnelle : toute information se rapportant à une personne physique identifiée ou identifiable (on protège
pas les personnes morales) Notez que le RGPD et la LIL s’appliquent aussi aux données papiers.
Il faut qu’il y ait une approche professionnelle pour que le RGPD s’applique.

Ce règlement s’applique dans l’ensemble de l’unoin européenne : à toutes les administrations et les entreprises privées
(tout le monde est soumis au RGPD à partir du moment où on est dans un cadre professionnel). Pour les données
européennes stockées ailleurs c’est au cas pas cas.
1. Le pays a sa propre loi et l’union européenne considère que la législation est similaire au RGPD (comme au Japon) :
ça se base sur des décisions d’adéquation, ce pays là en terme de décision il est adéquat, la réglementation est tellement
sévère qu’on retrouver celle du RGPD.
2. Les autres pays où ça coince beaucoup plus : quand on veut transférer des données de citoyens européens vers eux
il faut encadrer juridiquement : on va donc avoir une convention de transfert des données (on envoie la donnée mais il
faut qu’lle soit traitée similairement au RGPD, ce sont les closes contractuelles types) : par exemple on peut chiffrer
la donné.
On a beaucoup de problèmes de transfert avec les USA : ils ont développé le ”privacy shield”, les entreprises qui ont
obtenu cette certification se retrovent sur une liste du secrétaire au commerce, et pour obtenir cette certification il faut
que le gouvernement américain puisse accéder à la donnée si c’est pour la sécurité nationale : c’est la même logique de
l’adéquation. Maximilien Schrems (autrichien) : c’est le héros de la protection qui portera l’affaire devant la court de

9 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

justice européenne car c’est pas cohérent : s’il y a des organismes de rensiengment qui veulent accéder aux données,
elle peuvent et c’est contraire au RGPD.

Maintenant dans le périmètre de la réglementation, qui est le responsable ?

C’est le responsable de traitement : par exemple dans le cadre du production d’un film ce serait celui qui décide du
montage, il décide de la finalité des traitements ainsi que les moyens nécessaires à sa mise en oeuvre.
A l’université par exemple c’est pas la DSI mais la présidente de l’université (l’idée est qu’à un moment donné, tout
potentiellement peut remonter à la présidente). C’est pas la personne qui gère les inscriptions qui sera responsable !
En revanche si un employé perd son ordinateur dans le bus avec toutes ses données en clair, c’est sur lui qu’on ira
taper.
Distinction entre responsable est sous-traitent : celui qui sous-traite les données personnelles pour le compte de quel-
qu’un d’autre et sous l’instruction et l’auroité d’un responsable de traitement.

Avant le RGPD, le responsable de traitment devait déclarer tous ses traitements de données personnelles à la CNIL.
Avec le RGPD c’est une autre logique : accountability : l’idée est que le responsable de traitement doit être responsable
et pouvoir rendre des comptes dès lors qu’on lui en demade.
Plusieurs choses permettent de faire de l’accountability :
ˆ Tenue d’un registre de traitement : il enregistre chacun des traitements et pour ces derniers quelles données
sont traitées et qui y accède.
ˆ Privacy by design : la conformité au RGPD est prise en compte dès la conception de projets rattachées au
traitement des données.
ˆ Privacy by default : le responsable de traitement doit assurer par défaut le plus haut niveau de protection
(implique des mesures de de protection systématiques telles que la minimisation de la quantité de données et
de leur durée de conservation).
ˆ PIA (Privacy Impact Assessment) : pour les traitements à risque élevé, étude d’impact. Trois parties à détailler :
la description du traitement, l’évaluation juridique et l’évaluation technique. La CNIL ne sera consultée que si
le risque résiduel est élevé.
Les traitements qui remplissent 2 des critères suivants doivent subir un PIA : évaluation pour donner une note à
un client, décision automatique avec effet légal, surveillance systématique, collecte de données sensibles, collecte de
données personnelles à grande échelle, croisement des données, traitement des données d’une personne vulnérable,
usage innnovant.
Du coup on ne déclare quasiment plus rien à la CNIL ce qui lui allège son travail et lui permet de se concentrer sur
les cas les plus critiques (par exemple il faudra encore déclarer les énormes traitements de données de santé).

Continuons avec les droits des personnes :

ˆ Elles ont un droit à l’information : sur la finalité (pourquoi la donnée a été collecté), à qui elle va être destinée.
ˆ Un droit d’accès et rectification
ˆ Un droit d’opposition : possible de s’opposer pour des motifs légitimes à figurer dans un fichier (au niveau
commercial pas besoin de justification mais pour l’administration il faut un motif impérieux et on peu s’opposer
au droit d’opposition).
ˆ Un droit au déréférencement / effacement : introduit par le RGPD, permet de demander qu’on efface nos
données ou certain s résultats de recherche des moteurs de recherche.
ˆ Droit à la portabilité des données : lorsqu’on change d’opérateur modible on peut lui demande de transférer
nos données au nouvel opérateur sans avoir à les redonner.

Consentement des personnes : se fait sur une base légal (mon but est légal).
Il y a 6 possibilités pour recueillir / traiter de la donnée et le consentement en est la première.
2. On peut ne pas demander ce consentement si c’est nécessaire au respect d’une obligation légale : par exemple pour
le vote élecronique, la mise en place requiert le transfert des listes électorales : on est obligé de faire ce transfert et
donc on demande pas aux étudiants leur accord.
3. On peut également ne pas le demander si c’est pour la sauvegarde de la vie d’une personne : en coma ehtylique, je
peux pas donner mon identité, le médecin va pas attendre qu’on se réveille pour faire unr prise de sang.
4. C’est aussi valable pour une mission de service publique.
5. Exécution d’un contrat : baskets en lignes, on a pas décidé qu’on donnerait que la moitié du numéro de carte
bancaire et il leur faut bien l’adresse de facturation pour envoyer le produit.
6. Intérêt légitime : grosse éponge quand on ne sait pas quelle autre condition utiliser (typiquement dans les jeux aux
supermarchés on donne nore date anniversaire, ce qui est dans l’intérêt légitime du commercant pour récupérer des
clients). Quand le consentement est recueilli, il faut qu’il soit libre, spécifique (on dit oui pour une chose mais pas pour
les autres), éclairé (on est totalement informé) et univoque (c’est très clair).

Quelques obligations à la charge du responsable de traitement :

Il doit informer les personnes.
Il doit minimiser les quantités de données (less is more : ne pas prendre de données inutiles et minimiser le nombre de

10 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

personnes qui y accèdent).

La durée de conservation doit également être définie : archivage : on va la faire disparaı̂tre, soit on supprime soit on
anonymise. Par exemple à l’université le dossier d’inscription est gardé pour 50 ans de telle sorte que pour tout au
long de la vie active il soit possible à l’organisme de prouver qu’on s’est inscript.
Il doit également faire la vérification des transferts hors UE.
Et pour finir il a une obligation de sécuriser la donnée : donner des mesures pour garantir la confidentialité, l’intégrité
et la isponibilité des données personnelles.
Le plus important : avertir quand il y a des failles, quel est l’impact potentiel pour les personnes, si la faille est
dangereuse on envoie un mail à tout le monde (c’est une obligation). La communicaiton doit être faite dans les 72
heures dès la constatation.

La CNIL c’est un autorité administrative indépendante (elle ne dépend pas de l’état, ils n’ont pas de comptes à
lui rendre).
Elle a une mission d’information : toute personne peut s’adresse à la CNIL pour avoir de l’aide.
Mission de régulation : en 2019, une délibération super précise sur comment évaluer le niveau de sécurité pour un vote
électronique, elle prend également des doctrines très offensives pour les cookies.
Misson de contrôle et de sanction : vu qu’on déclare plus rien, la CNIL a renforcé ses missions de contrôle, elle vient
souvent aussi car il y a eu une plainte (on peut la contacter : ex : ca fait 4 fois qu’on demande un déréférencement
google et on peut demander à la CNIL). Elle sanctionne de manière graduelle : avertissement puis rappel à l’ordre
puis suspension du traitement des données (interdiction de continuer à traiter la donnée pendant un certain temps)
puis une amende (elle peut prendre soit 20 millions d’euros, ou 4% du chiffre d’affaires annuel mondial).

Le délégué à la protection des données à plusieurs rôles :

Informer et conseiller le responsable de traitement et les personnels.
Contrôler le respect du règlement et du droit national pour les données personnelles.
Conseiller sur la réalisation d’une analyse d’impact.
Exercer le relai avec la CNIL.
Veiller à la bonne tenue du registre et de la documentation.

11 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

5 Cours du 25/01/2024 - Pentest Web - Aloyse Ndong :

5.1 L’intervenant :
Aloyse NDONG.
Master cryptis 2014 - 2016.
CONIX security 2016 - 2022.
Atos 2022 - 2023.
Magellant sécuirté actuellement.

5.2 Présentation de l’audit :

Il y a plusieurs types d’audits : financiers, opérationnels, fonctionnels, ... Et on a d’autres audits plus spécifiques :
intégré (combine financier et opérationnel), administratif, audit du système d’information (ce sur quoi on va se concen-
trer), audit spécialisé, audit de forensic, ...
Un audit c’est une vue à un instant T de tout ou partie du SI pour le comparer à un référentiel (par exemple OWASP).
Pour les tests d’intrusion interne il n’y a pas de référentiel : méthodologies et bonnes pratiques. Cet audit va permettre
de répertorier les points forts mais surtout les points faibles du système. Puis des recommendations seront faites pour
corriger.
La démarhe pour la rélisation d’un audit se fait en 5 étapes : la lettre de mission, la planification de la mission,
la collecte des faits - test - preuves de concepts, entretien avec les audités, rédaction des livrables et pour finir une
présentation et discussion avec l’audité.
Les objectifs de l’audit sont de voir la réaction à une attaque, se faire une idée du niveau de sécurité, tester un nouvel
équipement, tester la mise ne place de la politique de sécurité où même évaluer l’évolution de la sécurité.

Risque : un évènement susceptible d’entraı̂ner dse dommages / des pertes pour l’entreprise. Il s’obtient en combi-
nant une potentialité avec un impact (une menace avec une vulnérabilité). 4 notions à retenir :
ˆ Menaces permanentes : peu importe notre sécurité, il peut toujours y avoir une menace.
ˆ Le risque est une cause de vulnérabilité due à une faiblesse du système.
ˆ Un risque arrive forcément tôt ou tard.
ˆ Maı̂trise du risque : mettre en place des mesures pour diminuer les niveaux de risques.
En revanche il ne faut pas confondre audit et analyse de risques : l’audit trouve les vulnérabilités mais ne dit pas si
elles sont tolérables pour l’etnreprise et l’analyse de risque permet de dire quels risques sont pris en compte / acceptés.
Le risque est accepté dans certains cas : faible probaiblité d’apparation / le coût de correction est plus grand que la
valeur des dommages.

La matrice de risques :

Quelques pratiques courantes :

Interviews : interrogation des personnes liées à la sécurité du SI, audit organisationnel.
Fuzzing : analyse comportementale d’une application face a des entrées aléatoires.
Relevé de configurations : explicite.
Audit de code : on regarde s’il y a de secrets dans le code ou autres vulnérabilités.

On a 3 types d’accès pour les tests d’intrusion :

ˆ Boı̂te noire : on est à l’extérieur et on ne sait pas ce qu’il y a à l’intérieur.
ˆ Boı̂te grise : quelques informations sur le système et on a un compte (mode ”utilisateur légitime”).
ˆ Boı̂te blanche : on a accès à tout (y compris le code)

Le résultat d’un audit se divise en 2 parties :

Les livrables : liste exhaustive des vulnérabilités trouvées et risques associés.

12 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

Des rapports adaptés à chaque interlocuteur client : ce seront soit des rapports techniques pour comprendre les
vulnérabilités, soit des rapports exécutifs pour avoir une vue globale de la sécurité du SI.
On a également un plan d’action qui va définir les mesures à prendre contre les vulnérabilités et les prioriser.

5.3 Présentation de l’audit appliqué aux applications web :

Ici, on va se focaliser sur :
L’intégrité : chaque document de l’application doit rester identique à l’original.
La confidentialité : certaines informations ne doivent pas être accessibles à tous.
La disponibilité : l’application web et ses fonctionnalités doivent rester accessibles à tout moment.
Traçabilité des utilisateurs : exemple des logs pour savoir qui a fait une action à un certain moment.

L’entreprise va mettre en place une politique de sécurité avec des règles et des procédures pour éviter les problèmes
sur l’application, définir des actions en cas d’intrustion et pour finir comment sensibiliser le personnel.
Le niveau de sécurité du SI c’est le niveau de sécurité du maillon le plus faible.
L’audit web : attaquer pour mieux protéger (le risque est toujours présent : tôt ou tard, les hackers passeront à travers
les protections). Il est très très rare d’avoir un SOC qui a détecté en quasi temps réel et bloqué.
Les vulnérabilités peuvent venir de plein d’endroits : changement de configuration, portails d’administration, mélange
de logiciels complexes sur les serveurs web.
Il existe également plusiers types de sites : sites statiques (que du HTML pas d’interaction), sites dynamiques (avec du
PHP / javascript), sites e-commerce, extranet, intranet, applications mobiles et ils ne devront pas tous être analysés
de la même manière.
Ex : portail d’administraitation exposé avec les identifiants par défaut : poentitalité = 4 (max) et impact = 4 (max) du
coup dans la matrice de risque ça nous donne un risque très élevé (toujours demander au client s’il a sa propre matrice).

5.4 Méthodologie d’audit appliquée aux applications web :

Nous allons avoir une quinzaine d’étapes pour réaliser l’audit réparties dans plusieurs grandes catégoriees : découverte
- reconnaissance - prise d’empreintes, logique applicative, gestion des accès, gestion des entrées, hébergement et ex-
ploitation des vulnérabilités.

Un outil très utile c’est Burpsuite :

Aller le télécharger depuis portswigger le community edition.
Burp c’est un proxy qui se met entre le navigateur et le serveur.
Aller dans les paramètres proxy : par défaut port à 8083 (on peut le laisser).
Pour l’interception des requêtes cocher les 2 lignes qui commencent par or, et pareil pour l’interception des réponses
(c’est dans proxy, setting, tools proxy).
Ensuite, on peut demarrer le browser intégré ou mettre en place un proxy dans firefox qui utilisera burp.
Ensuite problème de certificats : import / export CA certificate depuis burp (certificate in DER format), puis dans
firefox setting puis view certificates et add certificates.
Onglet HTTP history (dans proxy) : si on ouvre une page on voit l’historique des pages ouvertes, on peut ensuite faire
clic droit et enovyer vers le répéteur.
Dans Proxy ¿ Intercetp : intercept is on intercepte la requête, la bloque et puis on la modifie et puis on peut la renvoyer.

Ensuite il montre qu’on peut encoder les caractères : par exemple %20 pour l’espace, %26 pour l’esperluette.
Quaand on utilise des outils toujours savoir bien les utiliser.
Supprimer régulièrement les informations de session du navigateur lors d’un audit.
Quelques applications utilisent des load balancers (qu’il faut prendre en compte).

En premier on fait une cartographie de l’application : toujours utiliser un proxy, bien regarder les en-têtes (avec Burp
par exemple). On peut aussi consulter les ressources publiques. google dorking : intitle:unilim inurl:université
intext:Limoges
Pages status : donne des logs du serveur qui tourne (et donc on peut voir les paramètres et toutes les requêtes, mais
on ne verra pas les données si c’est un post, pour un get en revanche on aura les données).
filetype:env "DB PASSWORD" after:2018 aussi du dorking et il peut égalmenet être utilisé pour trouver des caméras.
Pour le contenu par défaut : utiliser des crawler (ex : Nikto, gobuster, ...)
Si on fait un test en production, il faut nous limiter sur certaines commandes (pour ne pas détruire le système du
client)
Se faire passer pour un utilisateur connecté / externe, voir ce que ça change si on enlève les cookies, ...
Trouver du contenu caché : lister les documents déjà trouvés pour prévoir les noms de fichiers cachés. Analyser le
code reçu à la recherche d’informations sur les serveurs / formulaires désactivés. On peut également automatiser la
recherche avec des dictionnaires.
Chercher les pages dans lesquelles on passe des paramètres via l’URL et si ce paramètre est un id encore mieux.

13 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

Essayer de comprendre la logique des fonctions et de l’application. Chercher également les pages qui ont un paramètre
de debug.
Résumé : déccouverte / observation, contenu visible, ressources publiques, contenu caché, paramètres intéressants +
outils

Partie 2 : analyse de l’application :

Identifier les fonctionnalités : on veut comprendre le but de l’application, les différents mécanismes de sécurité et les
fonctions annexes (redirections, téléchargements, ...)
On veut également identifier tous les points d’entrée possibles : comment l’utilisateur peut rentrer sur l’application
(quelles requêtes), étudier tous les mécanismes d’échanges et identifier tous les points d’accès des données.
Identifier les technologies utilisées : scripts Flash / applets / ActiveX, essayer d’identifier au maximum la liste de
stechnologies utilisées côté serveur, récupérer les versions, faire du finterprinting, regarder les extensions et rechercher
tous les composants tiers via du dorking.
Tout cela nous permet de faire un cartographie de la surface d’attaque : devenir la structure interne du serveur et des
fonctionnalités, faire la différence enre les fonctions qui intéragissent avec une base de données / non, pour chaque
composant lister les vulnérabilités fréquemment rencontrées, et pour finir faire un plan d’attaque pour chaque fonc-
tionnalité.
Outils : nmap, whatweb, wpscan, burp, ..., ou y aller manuellement

Partie 3 : les contrôles côté client :

Localiser tous les champs cachés, URL, cookis utilisés opur transmettre des données. Modifier ces valeurs pour essayer
de changer le comportement de l’application.
Contrôles côté client : entrées utilisateur,limite de la taille : esayer de contourner ces contrôles et chercher les éléments
HTML désactivés.
Test de composants tiers : applets javas (décompiler en téléchargeant le byte code), Ajax (utilisation de librairies
vulnérables, inejctions, XSS ?) et JQuery où on fera la même étude que pour Ajax.

Partie 4 : la logique applicative :

Identifier les points sensibles affectés par une mauvaise logique applicative : processus et formulaiers multi-niveaux (en
plusieurs séquences, peut on accédr au dernier niveau sans ceux d’avant), fonctions de login, logique des paramètres,
états non prévus par les développeurs.

Partie 5 : mécanisme d’authentification :

Compréhension du mécanisme (formulaire / certificats) et trouver toutes les pages relatives à l’authentification.
Qualité des mots dde passe : voir s’il ya une longueur minimale, essayer de s’enregistre avec des mots de passe faible,
s’authentifier en modifiant quelques lettres, ...
Enumérer les utilisateurs : identifiers les endroits où un onm d’utilisateur est envoyé au serveur, soumettre des requêtes
avec un nom valide / invalide pour voir la différence, si oui on peut lister les utilisateurs.
Tentatives d’authentification successives : on va répéter l’aopération d’authentification plusieur sfois avec un mauvais
mot de passe, puis un bon, et si l’authentification résusit le nombre d’authentifications successives n’est pas limité.
Fonctions de récupération de comptes : comment elle fonctionne (secret / challenge - response), indice sur le mot de
passe, ...
Rester connecté : voir l’effet de l’activation de cette fonctionnalité sur les cookies et essayer avec plusieurs comptes.
Unicité du nom utilisateur : s’enregistrer avec un nom déjà pris, erreurs de collision pour deviner un mot de passe.
Est-ce que les mots de passe sont facilement prédictibles ?
Transmission non-sécurisée d’identifians : passent-ils dans l’URL ou sont ils stockés dans le cookie ?
Lien d’acitvation / de récupération : le principe aléatoire est-il vraiment respecté, le lien est-il unique.
Logique de programme : envoyer des données d’authentification non-attendues (champs vides), si plusieurs requêtes
sont faites, les jour dans un ordre différent, rechercher des champs cachés.

Partie 6 : gestion des sessions :

Compréhension du mécanisme : jeton ? dans les cookies ? dans des champs cachés ? authentification HTTP ? infos
chiffrés ?
Etude des jetons : corrélation ente plusieurs jetons et noms d’utilisateur ? est-ce simpelment encodé / offusqué ?
Ex d’outils pour la prédictabilité du jeton : WebScarab Cookie Analyzer / Burp.
Le jeton est-il transmis sur une connxion sécurisée et les flags de sécurité lui sont-ils bien appliqués ?
Fuite d’informations dans les logs : est-ce que le jeton est logué, qui y a accès et le jeton est-il passé dans certaines
URL ?
Y-a-til une différence entre session et jeton : nouveau jeton à chaque nouvelle session ?
Fin de session : le jeton est-il toujours valable après, combien de temps après sa destruction, vol de session (répéteur
Burp).
Affectation du cookie : est-iil affecté avant l’authentification, est-il accepté dans l’URL et tests sur les formats de
cookie acceptés.

14 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

CSRF / XSRF : Corss-Site Request Forgery attack : l’idée est d’envoyer un lien frauduleux à l’administrateur pour
lui voler sa session.

Partie 7 : contrôle d’accès :

Comprendre les différents accès possibles sur l’application (types de comptes, ressources disponibles et protégées entre
utilisateurs, demandes de comptes avec le moins et le plus de privilèges)
Tests avec des comptes multiples : vertical et horizontal privilege segregation, sécurité par l’obscurité ?
Test avec accès limité : beaucoup plus compliqué, test d’accès aux interfaces d’administration.
Mauvaises implémentations : contrôle basé sur des paramètres cachés, contrôles basés sur le Referer.

Partie 8 : entrée utilisateurs :

Source de problème les plus fréquemment rencontrés.
Fuzzing de tous les paramètres dans les requêtes : soit manuellement soit avec des scripts perso, soit avec burp intruder
et on pourrait également utiliser des scanners de vulnérabilités.
Tests d’injection SQL : y-a-t’il un retour d’erreur (blind SQL ?), comportement de l’applicati on avec une quote, enco-
der les caractères spéciaux, essayer de changer les valeurs numériques par des nombres, quelles attaques sont possibles ?
OR1=1, UNION, fingerprint, ...
Tests XSS (Cross Site Scripting) : si le HTTP est parsé par le serveur dans du texte qu’on peut rentrer, on peut
mettre des balises script / img / video pour faire s’exécution du code. Vol de cookie, redirections, phishing, tunnel,
keylogger, ...
Tests injectoins de commandes : ping -i ou -n pour faire varier le temps de réponse, voir si le résultat de ls ou dir est
affiché, peut on envoyer des fichiers avec telnet ou netcat pour faire un reverse shell, pour finir chercher son niveau de
privilèges et essayer de l’élever.
Tests path traversal : est-ce qu’on peut faire ../../../../../../etc/passwd par exemple.
TEster l’injection e scripts et l’inclusion de fichiers (on pourrait mettre un script sur le serveur si c’est possible).
Soit on fait à la main, soit on peut utiliser Burp, Wfuzz, SQLmap, Beef, ...

Partie 9 : entrée dans les fonctions connexes :

Injections SMTP : changement du mail, des données, injections de caractères spéciaux et erreurs dans le HTML ?
Vulnérabilités logicielles : buffer overlflows, entiers signés non signés ou encore little et big endian ou le format des
chaı̂nes.
Injections SOAP : injection de données malformées dans un formulaire XML qui pourrait déclencher ces vulnérabilités
sur le serveur.
Injections LDAP : authentification LDAP, injection dans la base, test sur une série d’expressions connues.
Injections XPath.

Partie 10 : hébergement mutualisé.

Tests de ségrégations dans les infrastructures partagées et entre les applications partagées.

Partie 11 : tests relatifs au serveur web :

Identifiants par défaut : interfaces d’administration, scan de ports, documents des services utlisés, tester les mots de
passe connus, est-ce qu’un accès SSH par root est autorisé ?
Contenu par défaut : installation et pour les plugins.
Méthodes HTTP : lesquelles sont activées, est-ce qu’on peut faire OPTIONS, WebDEV activées ?
Proxy HTTP : peut on utiliser le serveur comme un proxy (avec CONNECT).
Test de mauvaise sconfigurations : changer le host dans les en-tête HTTP et changer la version de HTTP.
Test de vulnérabilités sur le serveur web : sur une version, dans les bases de vulnérabilités, dans le code source (si on
peut).

Partie 12 : tests divers :

Attaques DOM : insertions dans le javascript côté client, redirections, ...
Injection de frames : fonctionne seulement sur IE <= 7.
Vulnérabilités dans la politque de sécurité locale : expiration des cookies, cookies persitantes, mise en cache de pages
contenant du contenu sensible (cache-control : no-cache), transmission de paramètres sensibles via les URL et auto-
complétion des formulaires ?
Fuites d’informations : technologies utilisées, versions, structure interne, erreurs contenant des infos de débogage, ...
Chiffrement SSL / TLS : peut on faire les attaques connues ?
Exploitation des imprimantes mal configurées (interfaces d’administration non sécurisée, mots de passe par défaut).
Un outil pour faire ça c’est PRET (Printer Exploitation Toolkit).

15 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

5.5 Un peu de TP :
DVWA : aller chercher l’ISO
Ajouter un réseau privé d’hote
Se onnecter sur 192.168.56.101 avec ce login : admin, password
Sur la badstore on a une application web sur le port 80 (il faut faire un ifconfig eth1 192.168.56.102 pour lui set son
ip)
whatweb http ://192.168.56.102

Injection SQL :
SELECT * FROM users WHERE nom="toto"; : notre requête de départ.
payload : " OR "1" == "1
payload : " OR 1 == 1; --
La méthode la plus simple est d’essayer de provoquer une erreur
Sauf que les mots de passe sont pas généralement dans la table users mais dans la table passwords
SELECT * FROM users WHERE nom=""; : on va donner " UNION SELECT * FROM passwords : pour connaı̂tre le nombre
de colonnes dans la base on va utiliser un order by : ORDER BY 1 permet d’ordonner usr la première colonne (on va
pouvoir augmenter le nombre et tester quand ça marchera plus). Pour pouvoir faire l’union, on va rajouter des NULL
pour mettre le meme nombre de colonnes au 2 tables.
La faille SQL est dans le champ de recherche de badstore.net

Le site web fait : SELECT itemnum, sdesc, ldesc, price FROM itemdb WHERE ’$1’ IN (itemnum,sdesc,ldesc);

Blind sql : on a aucune réponse (pas d’erreur visuelle) : on joue avec d’autres variables (comme le code de retour)

sqlmap : par défaut sur Kali

’ or 1 = 1 sleep(3s) : si erreur atend 3 secondes avant le retour du code http, sinon ça veut dire qu’on est good
sqlmap -D database --tables : pour avoir les tables d’une database
sqlmap -D database -T table --columns : pour avoir les colonnes d’un table
tamper : space2comment change juste les espaces en commentaires
on peut aussi passer –level et –risk

Si mal fait, la BDD peut avoir acces en root au shadow et pourra ajouter des utilisateurs admin
(ajouter notre nom de compte, notre mot de passe hashé et rajouter ça au shadow)
si en deuxième on a x, pas besoin de mot de passe pour s’authentifier

Injection XSS :
Pour la XSS sur badstore on a un livre d’or que l’on peut signer
On peut envoyer <script>alert("test");</script> en commentaire
Le code est ajouté au code source de la page mais n’est pas encodé : c’et ce qui fait marcher la XSS
python3 -m http.server 8080 --bind 127.0.0.1 : pour demarrer un serveur http avec python
XSS volatile : l’injection n’est pas stocckée en base de données mais plutôt dans un URL

16 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

6 Cours du 01/02/2024 - Vote - Sylvain Ruhault :

6.1 Vote électronique :
Le vote traditionnel se fait dans une urne.
Les avantages qu’on attribute au vote électronique sont les suivants : une favorisation de la participation (c’est pas
sûr, si les gens ont pas envie d’aller voter ils iront pas), un comptage automatique (rend plus rapide le dépouillement)
et moins cher. Or, ce qui coûte le plus dans une élection (60%) c’est la propagande électorale au format papier (qui
sera toujours là même avec le vote électronique).
En France, on retrouver 2 types de vote électroniques :
ˆ Les machines à voter où il faut une présence au bureau de vote, l’avantage étant qu’elles permettent un comptage
efficace et rapide mais il y a tout de même la question de la confiance. C’est plus adapté à la belgique par exemple
où les bulletins de vote feraient une page s’ils étaient imprimés.
ˆ Le vote par internet qui peut se faire à domicile, est facile, permet de réduire les coûts (c’est discutable comme
on l’a dit avant) et on a aussi la question de l’influence parce qu’il n’y a plus d’isoloir et de personnes pour
intervenir en cas de soucis. L’idée sera donc de pouvoir voter plusieurs fois.

Avant la période de vote : gestion des listes électorales, gestion des listes de candidats, gestion du découpage électorale,
gestion des moyens d’authentification et la propagande électorale. Avec les machines à voter on a toujours besoin des
mêmes étapes, avec le vote par internet la gestion des moyens d’authentification va changer.
Pendant la période de vote : on authentifie l’électeur, on contrôle son appartenance à la liste électorale, on lui présente
les bulletins, on lui laisse réaliser son vote, il dépose son bulletin dans l’urne puis émargement, contrôle de la liste
d’émargement et contrôle de l’urne. Pour les machines à voter, la présentation des bulletins, la réalisation du vote, le
dépôt du bulettin et le contrôle de l’urne seront modifiés (c’est seulement le vote qui est numérisé mais pas l’authen-
tification). Pour le vote par internet tout est numérisé et donc toutes les étapes vont changer.
Finalement après le vote on dénombre les émargements, les bulletins (tant que c’est pas cohérent avec les émargements
on recompte), puis on dépouille les bulletins on totalise les suffrages et on proclame les résultats. Avec les machines
à voter le dénombrement des bulletins, leur dépouillement et la totalisation change. Pour le vote par internet tout
change sauf la proclamation des résultats.
Le vote par internet requiert donc une numérisation beaucoup plus forte.

En France, on ne peut utiliser le VPI que pour les élections législatives pour les français à l’étranger. Il est également
autorisé pour les élections non politiques : profesionnelles, représentants du personnel, primaires de partis politiques,
assications : une élection politique élit une personne qui a du pouvoir sur les citoyens.

On peut pouvoir plusieurs propriétés pour un vote et ces dernières peuvent être contradictoires (c’est pour ça que c’est
compliqué) :
ˆ Eligibilité : seuls les électeurs légitimes doivent pouvoir vote (+ protection contre le vote multiple = mettre
plusieurs bulletins dans la même envelope).
ˆ Robustesse : doit pouvoir tolérer des électeurs malveillants.
ˆ Exactitude : les résultats doivent correspondre aux suffrages exprimés.
ˆ Justice / fairness : pas de résultat préliminaire avant l’élection.
ˆ Vérifiabilité individuelle : chaque électeur doit pouvoir vérifier que son vote est pris en compte.
ˆ Vérifiabilité universelle (transparence implique la confiance) : représente le faire que n’importe qui peut assister
au dépouillement, n’importe qui peut entrer dans le bureau de vote : tout le monde peut vérifier quel les
résultats annoncés correspondent à la somme des votes exprimés.
ˆ Secret du vote : il ne doit pas y avoir de lien entre l’électeur et son choix (permet de résister à l’achat de vote : la
coercition), en revanche la vérifiabilité individuelle va favoriser l’achat de vote si on envoie un recu aux électeurs
(première contradiction).
Le bulletin de vote électronique : passe par l’ordinateur (première zone dangereuse), le FAI, puis le serveur : on peut
ne pas vouloir que la famille, les voisins, les collègues, le patron sachent ce qu’on a voté, la mafia peut également
acheter mon vote, les GAFAM peuvent être intéressés à manipuler le résultat de l’élection et il faut que ça marche
même quand l’état est compromis. Il y a également la possibilité d’une ingérence étrangère.

Usurpation d’identité : un attaquant vote à la place d’un électeur légitime (il peut être l’organisateur, un autre
électeur légitime ou il peut également être externe au scrutin).
Légitimité des électeurs : seuls les électeurs sur la liste électorale doivent pouvoir voter.
Vote à l’urne : constitution des listes électorales, l’identité de chaque électeur et sa présence sur la liste d’émargement
sont contrôlées physiquement par les membres du bureau de vote.
Vote par correspondance électronique : plus complexe que le vote à l’urne, il faut un système d’authentification des
électeurs et le risque d’usurpation d’identité doit être couvert sans la connaissance ou la possession du moyen d’au-
thentification, même en cas de succès de l’authentification il est difficile de se protéger contre un achat de vote / de la
coercition.

17 / 19 Année 2023 - 2024

DUVERGER Kévin Révisions - Sécu. app Université de Limoges

Atteinte à l’intégrité d’un résultat : atteinte à la volonté d’un ou plusieurs électeurs à l’insu de l’électeur et de l’orga-
nisateur : soit usurpation d’identité, soit altération du vote à l’insu de l’électeur, soit proclamation d’un résultat sans
accord avec la somme des votes.
Vote à l’urne : seuls les suffrages exprimés doivent être comptabilisés : contrôle de l’urne par le bureau de vote, l’urne
est transparente et fermée par 2 clés sous le contrôle de 2 personnes différentes, l’urne reste sous surveillance active
durant la durée du scrutin et pour finir n’importe quel observateur doit pouvoir venir surveiller les opérations de vote.
Validité de l’expression du vote : le vote des électeurs et le résultat ne doivent pas être altérés peu importe l’étape du
processus.
Vote par correspondance électronique : la vérification de la validité est plus complexe à cause du chiffrement, on peut
utiliser des protocoles zero-knowledge de cette façon n’importe qui pourra s’assurer que le bulletin est bien formé (un
seul vote à l’intérieur) sans jamais dévoiler le contenu du bulletin. Il faut également mettre en place de la vérifiabilité
avec des mécanismes permettant à n’importe quel observateur de vérifier que le scrutin s’est correctement déroulé et
aussi détecter les fraudes.
Vérifiabilité universelle : elle doit permettre aux électeurs de vérifier que leur choix de vote a bien été pris en compte
(cast as intended), de vérifier que leur bulletin a été correctement enregistré par le système de vote (recorded-as-cast)
et pour finir de vérifier que l’ensemble des bulletins a été correctement dénombré par le système de vote. Pour le
premier : audit du client de vote, pour les 2 autres on va donner un récipissé. Il faut également permettre à n’importe
quel oservateur de contrôler que ca s’est bien passé : génération de preuves mathématiques lors du dépouillement et
elles doivent ensuite pouvoir être vérifiées par n’importe qui.
Pour la transparence, que peut-on rendre public ?

El-Gamal :
Clé privée : un nombre x, clé publique : h = g x .
Chiffrement : c = (c1 , c2 ) = (g r , hr × m).
Déchiffrement : c2 /cx1 .
Sa sécurité repose sur le problème du logarithme discret : étant donné h et g il est difficile de retrouver x.
Problème CDH (Computational DH) : connaissant g x et g y il est difficile d’avoir g x×y .
Il sont difficiles si le modulo est sur 2048 voire 3072 bits et que c’est un premier safe : p = 2q + 1 avec q premier.

Chiffrement homomorphe :
ElGamal forme un chiffrement homomorphe : soit E(m) = (g r , hr × m) et E(n) = (g s , hs × n) on a que E(m × n) =
(g r+s , hr+s × m × n) = (g r × g s , hr × m × hs × n) = E(m) × E(n) mais il n’est pas adapté au vote électronique.
En revanche, le chiffrement qui va faire E(m) = (g r , hr × g m ) est également homomorphe mais avec une autre pro-
priété : E(m + n) = E(m) × E(n) ce qui est parfaitement adapté au vote électronique (un bulletin sera le chiffré d’un
0 / 1 et en les multipliant entre eux puis en déchiffrant on pourra compter, on a pas besoin de déchiffrer les bulletins
individuellement !).

Présente ensuite la cryptographie sur courbes elliptiques (qui offre des tailles plus petites).

Pour certains types de scrutins, la multiplication de bulletins est impossible : mixnets : l’idée est juste de mélanger les
bulletins des électeurs de façon à ne pas pouvoir relier un électeur à son bulletin.

On va vouloir 4 aspects pour la sincérité du scrutin : la légitimité des électeurs, la validité des bulletins, l’intégrité du
résultat (signifiant que le décompte final révèle la volonté exacte des électeurs), la transparence du scrutin.
Du côté du client, avec le schéma ElGamal précédent on pourrait très bien imaginer un électeur qui enverrait autre
chose que 0 ou 1 et qu’il faudrait détecter. En plus avec ElGamal n’importe qui peut re-randomiser un texte chiffré et
invalider un bulletin.
On veut des preuves de sécurité pour s’assurer que ces attaques ne peuvent pas exister.
On peut également signer les bulletins mais cela peut avoir un impact sur le secret du vote.

18 / 19 Année 2023 - 2024