Questions d'entretien Penetration Tester

On ne le déchiffre pas — les hashs cryptographiques sont des fonctions à sens unique sans inverse. « Cracker » un hash, c'est deviner des entrées candidates, les hacher et comparer (dictionnaire, force brute, rainbow tables), ce qui explique justement pourquoi on utilise des hashs lents et salés pour les mots de passe. Aucune clé ne « déchiffre » un hash. Si une donnée peut être déchiffrée, c'est qu'elle a été chiffrée, pas hachée — et le Base64 est un encodage réversible, pas du hachage.

Non. Toute la plage 127.0.0.0/8 est réservée au bouclage, donc 127.0.0.2, 127.1.1.1, et ainsi de suite résolvent toutes vers l'hôte local. C'est crucial pour le SSRF et le contournement de listes d'autorisation — un attaquant peut utiliser 127.0.0.2 ou d'autres encodages pour esquiver un contrôle naïf « bloquer 127.0.0.1 » — et pour lier plusieurs services locaux. (En IPv6, le bouclage est l'unique adresse ::1.)

Non. Une MAC est attribuée par le fabricant (OUI plus identifiant de l'appareil) et « gravée », mais pratiquement chaque système d'exploitation permet de la remplacer en logiciel (macchanger, ip link set address). Les adresses MAC sont donc usurpables et ne doivent pas servir à l'authentification — le filtrage MAC est faible, et les téléphones randomisent désormais leur MAC par confidentialité. « Permanente et unique » est l'idée fausse.

Non. POST place simplement les paramètres dans le corps de la requête au lieu de l'URL ; ce corps est en clair et parfaitement visible pour quiconque voit le trafic, sauf en HTTPS. POST est préférable pour les actions qui modifient l'état et garde les paramètres hors des URL, des journaux et de l'historique, mais il n'offre aucune confidentialité en soi. L'erreur confond « pas dans l'URL » et « chiffré » — seul TLS chiffre les données de l'une ou l'autre méthode en transit.

Question piège : il n'existe pas de port unique pour traceroute. Le traceroute Unix classique envoie des datagrammes UDP vers des ports élevés et improbables à partir de 33434 environ, avec un TTL croissant ; le tracert de Windows utilise plutôt ICMP Echo. Il fonctionne en lisant les messages ICMP Time Exceeded que renvoient les routeurs à l'expiration du TTL, et non en visant un port réservé. Et ICMP lui-même n'a aucun port.

Si un attaquant peut téléverser un fichier exécutable côté serveur (ou du HTML/SVG) dans un répertoire servi, il peut obtenir une exécution de code à distance ou un XSS stocké. Validez le vrai type de contenu, stockez les fichiers hors de la racine web ou sur un stockage non exécutant, randomisez les noms de fichiers et servez-les de manière à empêcher leur exécution ou leur interprétation comme balisage. Les chargements de page plus lents et la consommation disque sont des problèmes opérationnels, pas le risque de sécurité exploité ici.

Les règles d'engagement excluent généralement le déni de service en production, et un plantage non planifié cause un dommage réel à l'activité et peut annuler la mission. Vérifiez d'abord le périmètre ; si une preuve de concept destructrice n'est pas autorisée, prouvez la vulnérabilité par des moyens plus sûrs et documentez clairement l'impact probable. Lancer l'exploit pour une capture d'écran est imprudent. Le lancer à répétition pour des « métriques de fiabilité » multiplie la panne. Le passer sous silence cache au client un risque sérieux et exploitable.

Les missions professionnelles se terminent par un nettoyage complet et un inventaire des artefacts, pour ne pas laisser de nouvelle surface d'attaque ni brouiller l'environnement du client. Laisser des shells ou des comptes au client à trouver est négligent et dangereux — un vrai attaquant pourrait les réutiliser. Conserver une porte dérobée « pour la prochaine fois » est contraire à l'éthique et probablement illégal. Supprimer vos propres journaux d'activité détruit la piste d'audit dont le client a besoin pour valider le test et reconstituer ce que vous avez fait.

Ce qui compte, c'est l'impact : un identifiant de service réutilisé ou surprivilégié qui débloque l'admin du domaine ou des systèmes critiques est le constat qui compte, alors testez la réutilisation et cartographiez les privilèges et le chemin de mouvement latéral. Casser d'abord tous les autres hashs est une perte de temps qui retarde l'essentiel. Changer le mot de passe du compte de service est destructeur, casse la production et alerte les défenseurs. Envoyer un identifiant actif en clair par e-mail est en soi une exposition et une mauvaise hygiène opérationnelle.

Découvrir une intrusion active est une urgence hors bande : les règles d'engagement doivent définir une procédure d'escalade, alors déclenchez-la immédiatement, préservez les preuves et évitez de contaminer un incident en cours. Continuer à tester peut interférer avec le vrai attaquant ou détruire les preuves mêmes dont les intervenants ont besoin. Tenter d'expulser l'attaquant vous-même est hors périmètre, risqué et peut l'alerter. Attendre le rapport final pourrait signifier des jours de violation continue et de perte de données.

Les tests d'ingénierie sociale doivent rester dans des prétextes convenus et éthiques : assez réalistes pour être utiles, mais sans coercition, sans usurper une autorité ni exploiter des situations personnelles ou médicales. Une réinitialisation générique de mot de passe IT convenue dans les règles d'engagement est acceptable. Se faire passer pour l'enfant malade d'un vrai employé ou menacer quelqu'un de licenciement cause un véritable préjudice psychologique. Se faire passer pour les forces de l'ordre usurpe une autorité et est souvent illégal, même avec une mission signée.

Prouvez la vulnérabilité sans nuire au client ni accumuler ses données : montrez que vous pouvez lire des données arbitraires via la version de la base, le schéma ou un seul échantillon anonymisé, puis arrêtez-vous. Extraire l'intégralité des données personnelles crée une responsabilité de notification de violation et de traitement pour les deux parties. Supprimer une table est destructeur et dépasse de loin la preuve de concept. Chiffrer la base et exiger une prime, c'est de l'extorsion, pas un test : c'est un délit, pas un constat.

L'autorisation définit la mission : tester hors du périmètre convenu est potentiellement illégal et viole les règles d'engagement, aussi tentante que soit la cible. Documentez ce que vous avez vu, arrêtez-vous et obtenez l'accord écrit du client avant d'aller plus loin. Exploiter pour « plus de constats » ne justifie jamais un accès non autorisé. L'exploiter discrètement en pensant ne pas être pris est à la fois contraire à l'éthique et un délit, et étendre le périmètre vous-même prive le client de son consentement éclairé.

Un rapport utile pousse à la remédiation : classez par risque métier (probabilité × impact), mettez en avant les chaînes d'exploitation qui mènent à une compromission critique et donnez des correctifs actionnables pour chaque constat. Le classement alphabétique enterre l'essentiel sous ce qui commence par « A ». Le plus long écrit d'abord récompense le verbiage plutôt que la gravité. Supprimer les constats faibles cache un risque réel et les motifs dont le client a besoin pour la défense en profondeur, le laissant avec une image faussement rassurante.

IMDS est un point d'accès link-local (169.254.169.254) qui fournit à une instance ses métadonnées, dont les identifiants temporaires de son rôle IAM attaché. La SSRF peut tromper le serveur pour qu'il récupère cette URL et fasse fuiter ces identifiants. IMDSv2 exige un PUT pour obtenir un jeton de session à courte durée de vie, définit une limite de saut (hop limit) / TTL IP par défaut de 1, et rejette les requêtes avec certains en-têtes — si bien qu'un simple GET de SSRF ne peut plus l'atteindre.

Les erreurs classiques sont des ACL publiques ou des politiques de bucket autorisant un accès anonyme ou à tous les utilisateurs AWS, des principaux trop larges ou des actions avec wildcard, l'absence de chiffrement par défaut et l'absence de journalisation. On les évite en activant le Block Public Access au niveau du compte, en utilisant des politiques IAM/bucket selon le moindre privilège, en imposant le chiffrement par défaut et TLS, et en activant la journalisation des accès et des règles Config pour détecter les dérives.

RSA est un algorithme asymétrique utilisé pour chiffrer des données ou créer des signatures numériques à l'aide d'une paire de clés. Diffie-Hellman est un protocole d'accord de clé qui permet à deux parties de dériver un secret partagé sur un canal public sans jamais le transmettre. Ils résolvent des problèmes différents : RSA prouve l'identité et peut encapsuler des clés ; DH négocie une clé de session — et sa variante éphémère assure la confidentialité persistante.

Un HMAC est un code d'authentification de message à clé : il hache le message avec une clé secrète via une construction imbriquée (hachage interne et externe avec des bourrages dérivés de la clé). Il prouve à la fois l'intégrité (le message n'a pas été altéré) et l'authenticité (il vient de quelqu'un détenant la clé). Un simple hachage ne prouve ni l'un ni l'autre, puisque n'importe qui peut le recalculer ; HMAC résiste aussi aux attaques par extension de longueur.

Un JWT comporte trois parties en base64url — en-tête, charge utile (revendications) et signature — réunies par des points. Le serveur signe l'en-tête et la charge utile avec un secret ou une clé privée, et vérifie cette signature à chaque requête pour faire confiance aux revendications sans état de session côté serveur. Pièges : accepter alg=none, la confusion de clés RS256 vers HS256, ne pas valider l'expiration/l'émetteur/l'audience, mettre des secrets dans la charge utile lisible, et l'absence de voie de révocation.

Kerberos repose sur un centre de distribution de clés (KDC) de confiance. Le client s'authentifie une fois auprès du serveur d'authentification et obtient un ticket d'octroi de tickets (TGT) chiffré avec la clé du KDC. Pour atteindre un service, il présente le TGT au service d'octroi de tickets et reçoit un ticket de service chiffré avec la clé de ce service. Le service le déchiffre et lui fait confiance. Les mots de passe ne traversent jamais le réseau, et les tickets ont une durée limitée.

Le client et le serveur se mettent d'accord sur un secret partagé en un seul aller-retour grâce au Diffie-Hellman éphémère (ECDHE). Le ClientHello transporte les groupes pris en charge et un key share ; le serveur répond avec son key share et son certificat, les deux parties dérivent les mêmes clés, et les données applicatives circulent immédiatement, avec la confidentialité persistante par défaut.

Ni l'un ni l'autre. ARP est un protocole de couche 2 (couche liaison) encapsulé directement dans une trame Ethernet, et non dans un paquet IP. Comme il ne circule jamais sur IP, il ne peut utiliser ni TCP ni UDP, qui sont des transports de couche 4 nécessitant IP en dessous. Le rôle d'ARP est de résoudre une adresse IP connue en l'adresse MAC correspondante sur le même segment de réseau local.

Cela confirme le XSS. Si alert() s'est déclenché du tout, c'est que le navigateur a analysé et exécuté votre JavaScript injecté dans le contexte de la page : c'est la vulnérabilité. Une fenêtre vide signifie simplement que l'argument chaîne que vous avez transmis ne s'est pas affiché comme prévu (gestion des guillemets, encodage ou altération du contexte ont cassé le message), pas que la charge est bloquée. Le point d'exécution est actif ; vous affinez la charge à partir de là.

Filtré. Un port filtré rejette silencieusement le paquet, donc le scanner n'obtient aucune réponse et doit attendre un délai d'expiration : il n'apprend rien sur l'existence même de l'hôte, et le scan est considérablement ralenti. Un port fermé renvoie un RST TCP, qui confirme que l'hôte est vivant et répond, offrant gratuitement à l'attaquant une valeur de reconnaissance.

Pas à lui seul. HTTPS empêche le MITM uniquement quand la validation du certificat est strictement appliquée et que le client atteint le site en HTTPS dès le départ. Si une AC malveillante est de confiance (proxy d'entreprise, racine installée par un logiciel malveillant), si l'utilisateur passe outre les avertissements de certificat, ou si du SSL stripping rétrograde la connexion vers HTTP avant le démarrage de TLS, un attaquant peut toujours se placer au milieu.

Question piège : ping n'utilise aucun port. Il s'exécute sur ICMP, un protocole de couche 3 qui repose directement sur IP. Les ports n'existent que dans les protocoles de couche 4 comme TCP et UDP, donc ICMP (et donc ping) n'en a aucun. ICMP utilise à la place des champs de type et de code, par ex. Echo Request type 8 et Echo Reply type 0.

Trois. Le client envoie un SYN, le serveur répond par un SYN-ACK combiné (un seul paquet qui à la fois accuse réception du SYN du client et envoie le propre SYN du serveur), et le client termine par un ACK. L'astuce est que SYN-ACK est un seul paquet, pas deux, donc le total est de trois — exactement ce que désigne « en trois temps ».

La divulgation coordonnée de vulnérabilités est un processus où un chercheur signale une faille en privé à l'éditeur, les deux parties s'accordent sur la correction et un délai, et les détails ne sont publiés qu'une fois un correctif disponible (ou le délai convenu écoulé). Elle équilibre le temps laissé aux défenseurs pour corriger et le droit du public à être informé. Un fichier security.txt et une politique claire rendent le signalement sans friction ; les programmes de bug bounty ajoutent des récompenses structurées par-dessus.

Le WSTG est une méthodologie adossée à une checklist qui fait passer une application par des catégories de test : collecte d'informations, configuration et déploiement, identité et authentification, autorisation, gestion de session, validation des entrées (injection/XSS), gestion des erreurs, cryptographie, logique métier et côté client. Il offre une couverture systématique avec des identifiants de test stables, de sorte que les constats sont reproductibles et que rien d'évident n'est oublié.

PTES définit sept phases : pré-engagement (périmètre, règles d'engagement, autorisation), collecte de renseignements (OSINT, reconnaissance), modélisation des menaces, analyse de vulnérabilités, exploitation, post-exploitation (pivotement, données de valeur, persistance) et reporting. La structure rend les missions reproductibles, défendables et liées au risque métier plutôt qu'à du hacking improvisé. Le pré-engagement et le reporting sont les phases que les juniors sous-estiment.

Le purple teaming est collaboratif plutôt qu'adversarial : le côté rouge exécute des TTP précis et convenus (souvent reliés à MITRE ATT&CK) pendant que le côté bleu observe sa télémétrie en temps réel pour confirmer si chaque technique est journalisée, alertée et détectable. On mesure la couverture de détection technique par technique, on ajuste les détections et comble les lacunes immédiatement, puis on re-teste. Le livrable est une détection améliorée et mesurable — pas une liste de qui a « gagné ».

Un pentest vise une large couverture — trouver autant de vulnérabilités que possible dans une cible délimitée. Une red team est une émulation d'adversaire pilotée par objectif : choisir un but (par ex. atteindre les données les plus précieuses), émuler les TTP d'un acteur de menace précis, rester furtif pour tester la détection et la réponse, et éviter le scan bruyant. La red team mesure l'équipe bleue et toute l'organisation, pas seulement l'actif ; les deux exigent des règles d'engagement strictes et une autorisation.

SSH utilise TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS le 53 (UDP et TCP), RDP TCP 3389 et SMB TCP 445. Connaître les ports réservés permet de lire la sortie d'un scan, d'écrire des règles de pare-feu et de trier les alertes rapidement — un service sur son port attendu plutôt qu'inattendu est un signal immédiat.

On commence par un scan complet des ports TCP, puis on énumère en profondeur chaque service ouvert — bannières, versions, identifiants par défaut, accès anonyme et contenu web — avant de toucher au moindre exploit. La plupart des machines tombent grâce à une énumération minutieuse, pas à des exploits astucieux, ce qui est le cœur de l'état d'esprit « try harder ».

Le scan nmap par défaut ne couvre que les 1000 ports les plus courants, donc un service sur un port haut serait entièrement manqué. Le schéma efficace est un scan SYN rapide des 65535 ports d'abord, puis un scan ciblé de versions et de scripts par défaut uniquement sur les ports trouvés ouverts.

Énumérez méthodiquement : vérifiez sudo -l, les binaires SUID/SGID, les tâches cron, la version du noyau et de l'OS, les fichiers inscriptibles dans des chemins privilégiés, les capabilities et les identifiants stockés. Des outils comme LinPEAS automatisent le balayage, mais vous vérifiez chaque découverte avec GTFOBins ou une technique connue.

Identifiez le service et la version exacts, cherchez sur Exploit-DB ou searchsploit un PoC correspondant, puis lisez le code ligne par ligne avant de l'exécuter — corrigez l'IP cible, le port et l'adresse du reverse shell, régénérez tout shellcode, et comprenez ce qu'il fait pour qu'il ne se retourne pas contre vous.

Identifiez d'abord le format du hachage (hashid ou contexte), puis lancez hashcat ou John avec le mode correct contre une wordlist comme rockyou, en appliquant des règles pour muter les candidats. Utilisez le bon flag de format (NTLM, sha512crypt, NetNTLMv2, etc.) pour que l'outil hache les essais de la même façon que la cible.

Utilisez l'hôte compromis comme relais vers le sous-réseau inaccessible. Mettez en place une redirection de port pour un service unique, ou un proxy SOCKS dynamique (SSH -D ou chisel) et routez vos outils à travers lui avec proxychains, pour que votre machine d'attaque atteigne les hôtes internes via le pivot.

Pour SMB, énumérez les partages, vérifiez l'accès anonyme/session null, listez les utilisateurs et identifiez la version pour les CVE connues. Pour SNMP, essayez les community strings par défaut comme « public » et parcourez la MIB pour extraire noms d'utilisateurs, processus en cours, logiciels installés et détails réseau.

On lance un pseudo-terminal (généralement python -c 'import pty; pty.spawn("/bin/bash")'), on le met en arrière-plan avec Ctrl-Z, on exécute stty raw -echo côté local, on le remet au premier plan, puis on réinitialise TERM et le nombre de lignes/colonnes. On obtient un TTY complet avec contrôle des tâches, complétion par tabulation et éditeurs fonctionnels.

Identifiez la stack à partir des en-têtes et du source, puis brute-forcez répertoires et fichiers avec gobuster ou feroxbuster en utilisant une bonne wordlist et les extensions pertinentes. Cherchez panneaux d'administration, sauvegardes, fichiers de configuration et points d'upload, et vérifiez les hôtes virtuels quand le site répond à un nom d'hôte.

Énumérez les privilèges actuels (whoami /priv), les services mal configurés (permissions faibles, chemins de service non quotés), AlwaysInstallElevated, les tâches planifiées, les identifiants stockés et les correctifs manquants. WinPEAS ou PowerUp automatisent le balayage ; les abus de privilèges de jetons comme SeImpersonate sont des gains fréquents à forte valeur.

Isolément, une SQLi expose ou modifie des données et peut atteindre le RCE ; une XSS stockée détourne les sessions dans le navigateur des victimes. Enchaînées, vous pouvez utiliser la SQLi pour implanter une charge XSS stockée qui se déclenche dans la session d'un admin, voler sa session et passer au contrôle total de l'application.

Tout utilisateur du domaine authentifié peut demander un ticket de service Kerberos (TGS) pour n'importe quel compte ayant un SPN. Ce ticket est chiffré avec le hachage de mot de passe NTLM du compte de service ; vous l'extrayez et cassez le mot de passe hors ligne — aucun accès privilégié requis au départ, et c'est quasi silencieux.

La reconnaissance passive recueille des informations sans interagir directement avec les systèmes de la cible — OSINT, enregistrements DNS, transparence des certificats. La reconnaissance active touche la cible, comme le balayage de ports ou la capture de bannières, ce qui est plus bruyant mais donne plus de détails.

Un test d'intrusion passe par le pré-engagement (cadrage et règles d'engagement), la reconnaissance, le balayage et l'énumération, l'exploitation, la post-exploitation et le reporting. Chaque phase alimente la suivante, et le reporting est le moment où la valeur est réellement livrée au client.

Le pivoting transforme un hôte compromis en relais pour atteindre des segments internes vers lesquels votre machine ne peut pas router. Vous utilisez le port forwarding, un proxy SOCKS sur votre canal C2 (par ex. Chisel, le forwarding dynamique SSH) ou un routage par agent, puis vous lancez des outils à travers ce tunnel pour attaquer le sous-réseau suivant.

Énumérez d'abord : privilèges actuels, droits sudo, binaires SUID/SGID, tâches cron, fichiers inscriptibles dans le PATH, version du noyau et identifiants stockés. Puis exploitez le chemin le plus simple et fiable — souvent une règle sudo mal configurée ou un GTFOBin SUID — avant de recourir à un exploit du noyau.

Énumérez les privilèges du compte et les mauvaises configurations de l'hôte : privilèges de jeton comme SeImpersonate, chemins de service non entre guillemets, permissions de service faibles, AlwaysInstallElevated et identifiants stockés. Puis abusez du plus fiable — l'usurpation de jeton (attaques Potato) est une voie courante vers SYSTEM.

Un bind shell ouvre un port d'écoute sur la cible et attend que vous vous y connectiez. Un reverse shell fait que la cible se connecte en sortie vers un écouteur que vous contrôlez. Les reverse shells l'emportent généralement car le trafic sortant contourne les règles de pare-feu entrantes et le NAT.

Un scan de vulnérabilités est un inventaire automatisé, en largeur, des faiblesses potentielles, souvent avec des faux positifs. Un test d'intrusion est mené par un humain : il valide les trouvailles, les enchaîne et démontre un impact métier réel par une exploitation effective.

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.

Le CSRF piège le navigateur d'un utilisateur connecté pour lui faire envoyer une requête modifiant l'état vers un site où il est authentifié, en abusant du fait que les cookies sont envoyés automatiquement. On l'empêche avec des jetons anti-CSRF (une valeur secrète par session que l'attaquant ne peut ni lire ni deviner) et l'attribut de cookie SameSite, qui empêche les cookies d'accompagner les requêtes intersites.

Le Top 10 de l'OWASP est un document de sensibilisation piloté par la communauté qui classe les risques de sécurité des applications web les plus critiques, actualisé tous les quelques années à partir de données réelles. Ce n'est ni une liste de contrôle ni une norme, mais un point de départ — les entrées récentes incluent le contrôle d'accès défaillant (n°1), les échecs cryptographiques, l'injection et la conception non sécurisée.

Les requêtes préparées envoient d'abord le modèle de requête à la base de données, avec des emplacements réservés, afin que la structure soit figée avant l'arrivée de toute donnée utilisateur. Les paramètres sont ensuite liés comme de pures données et ne peuvent jamais être interprétés comme du SQL — ainsi une entrée comme ' OR 1=1 est traitée comme une chaîne littérale, pas comme du code. Cette séparation est le correctif canonique et fiable contre l'injection.

La défense principale est l'encodage de sortie contextuel — encoder les données non fiables pour l'endroit exact où elles atterrissent (corps HTML, attribut, JavaScript, URL). Associez cela à des API DOM sûres (textContent plutôt qu'innerHTML), à l'auto-échappement des frameworks, à la validation des entrées et à une Content-Security-Policy comme rempart de défense en profondeur qui limite quels scripts peuvent s'exécuter.

La Same-Origin Policy est la règle du navigateur selon laquelle un script d'une origine (schéma + hôte + port) ne peut pas lire les réponses d'une origine différente, ce qui protège les sessions authentifiées. CORS est un assouplissement contrôlé : un serveur renvoie des en-têtes Access-Control-Allow-Origin pour autoriser explicitement des origines spécifiques à lire ses réponses, ce qui assouplit la SOP au lieu de la contourner.

HttpOnly cache le cookie à JavaScript afin que le XSS ne puisse pas le voler via document.cookie. Secure garantit que le cookie n'est envoyé que sur HTTPS, bloquant l'interception réseau. SameSite contrôle si le cookie est envoyé sur les requêtes intersites, atténuant le CSRF. Ensemble, ils renforcent les cookies de session contre les voies de vol et d'abus les plus courantes.

L'injection SQL permet à l'entrée d'un attaquant de modifier une requête. Les techniques en bande renvoient les données directement : celle basée sur UNION ajoute un UNION SELECT pour extraire des colonnes supplémentaires, et celle basée sur les erreurs fait fuiter les données via les messages d'erreur de la base. Quand aucune sortie n'est visible, les attaquants utilisent la SQLi à l'aveugle — la booléenne déduit les données des différences de réponse vrai/faux, et la temporelle utilise des délais comme SLEEP() pour lire les données bit par bit.

Le SSRF pousse un serveur à effectuer des requêtes HTTP (ou autres) vers une destination choisie par l'attaquant, en abusant de la position réseau du serveur pour atteindre des services internes derrière le pare-feu. Dans le cloud, c'est particulièrement grave car le service de métadonnées d'instance (par exemple 169.254.169.254) peut renvoyer des identifiants IAM, transformant un SSRF en compromission du compte cloud.

Tout XSS injecte un script contrôlé par l'attaquant dans le navigateur d'une victime. Le XSS stocké persiste la charge utile sur le serveur (par exemple un commentaire) et touche tous ceux qui la consultent ; le XSS réfléchi renvoie la charge utile depuis le serveur dans une seule réponse, généralement via un lien forgé ; le XSS basé sur le DOM n'atteint jamais la logique serveur — du JavaScript côté client vulnérable écrit une entrée non fiable dans la page.

Le XXE abuse d'un analyseur XML qui résout les entités externes définies dans la DTD d'un document. Un attaquant déclare une entité pointant vers un fichier local ou une URL interne, et l'analyseur la récupère — permettant la divulgation de fichiers, le SSRF et le déni de service. Le correctif est de désactiver le traitement des DTD et la résolution des entités externes dans la configuration de l'analyseur.