Montrez-moi comment vous combineriez des bugs web courants — disons une injection SQL et une XSS — pour produire un impact dépassant une simple trouvaille.

Un bon pentester web raisonne en chaînes d'attaque, pas en listes de contrôle. Un scanner signale « XSS réfléchie, moyenne » et « SQLi, haute » comme deux lignes distinctes. Un testeur montre comment, ensemble, elles deviennent « prise de contrôle complète de l'admin, critique ». C'est ce récit qui motive la remédiation.

Ce que chaque bug vous apporte seul

• L'injection SQL vous permet de lire, modifier ou supprimer des données auxquelles l'application fait confiance. Selon la base de données et les privilèges, elle peut escalader davantage : extraire des hachages de mots de passe, lire des fichiers (LOAD_FILE), écrire un web shell, voire un RCE via des fonctionnalités comme xp_cmdshell (MSSQL) ou des requêtes empilées.
• Le cross-site scripting, en particulier la XSS stockée, exécute du JavaScript de l'attaquant dans le navigateur d'un autre utilisateur — vous permettant de voler des jetons de session, d'agir au nom de cet utilisateur ou d'enregistrer ses frappes sur la page.

La chaîne

Considérez une application où les « notes » des clients sont stockées via un backend SQL puis affichées dans un panneau de revue admin sans encodage de sortie correct :

1. Injecter via SQLi ou un champ stocké : vous placez une charge XSS stockée dans un enregistrement — directement via le formulaire, ou en utilisant l'injection SQL pour écrire la chaîne malveillante dans une colonne à laquelle l'application fait confiance et qu'elle affiche.
2. Déclenchement dans un contexte privilégié : un admin ouvre le panneau de revue ; votre JavaScript s'exécute dans sa session authentifiée.
3. Voler la session / agir en tant qu'admin : la charge exfiltre le cookie de session de l'admin (ou, s'il est HttpOnly, effectue des requêtes authentifiées en son nom via l'API de l'application) pour créer un nouvel utilisateur admin ou modifier des paramètres.
4. Approfondir via SQLi : avec un accès admin, vous revenez à la SQLi pour extraire toute la table des utilisateurs, casser les hachages et viser le RCE sur l'hôte de la base de données — pivotant de l'application web vers l'infrastructure.

Chaque étape est modeste ; la chaîne est une compromission critique.

Pourquoi cela compte dans le rapport

Montrer la chaîne réaliste recadre le risque, de « deux bugs web » vers « un attaquant prend le contrôle de l'admin et de la base de données », ce qui est le langage qui fait avancer les corrections.

Ce que recherchent les recruteurs

Une pensée par enchaînement, une mécanique exacte pour chaque bug (XSS stockée dans un contexte privilégié, chemins SQLi-vers-RCE), et l'instinct de traduire la chaîne en impact métier plutôt que de réciter les catégories OWASP.