Les classiques à connaître
6 pages
XSS, SSRF, débordement de pile, contrôle d’accès par identifiant, traversée de chemin : les failles que tout le monde connaît et que l’on retrouve pourtant chaque année.
Section
Des vulnérabilités et des techniques d'attaque démontrées en laboratoire, sur des ouvrages construits pour l'occasion : le mécanisme, la preuve, la contre-mesure.
Rubrique · 34 pages · 11 sous-sections
6 pages
XSS, SSRF, débordement de pile, contrôle d’accès par identifiant, traversée de chemin : les failles que tout le monde connaît et que l’on retrouve pourtant chaque année.
2 pages
Oracles de remplissage contre RSA et CBC : quand la cryptographie bavarde sur ses erreurs.
3 pages
Jetons d’accès volés, confusion de portée OAuth et webhooks forgés : voler une identité sans mot de passe.
5 pages
En-tête Host, confusion de chemin, empoisonnement de cache et type MIME deviné : les pièges entre client et serveur.
5 pages
Injection SQL aveugle, téléversement piégé, désérialisation et pollution de prototype : quand l’entrée devient du code.
3 pages
Relais NTLM, détournement de DLL et imprimantes réseau : les failles du parc Windows.
6 pages
SUID, conditions de course, variables d’environnement et jetons de service : s’élever sous Linux et Kubernetes.
1 page
Rançongiciels et logiciels destructeurs qui se propagent seuls d’un poste à l’autre, jusqu’à mettre toute l’organisation à l’arrêt.
1 page
Les affaires où tout se joue après l’intrusion : alerte ignorée, détection tardive, crise bien ou mal conduite.
1 page
Données publiées, mal effacées ou captées au passage : quand aucune intrusion n’est nécessaire pour identifier des personnes.
1 page
Chatbots détournés par injection d’instructions, fuites par l’usage et agents trop obéissants : quand l’assistant fait ce qu’on lui dit.
Commencer par les classiques
Voir une entrée devenir du code
Voir comment on vole une identité
Explorer les pièges entre client et serveur
Finir par les oracles cryptographiques
Cette section rassemble les articles qui documentent une vulnérabilité ou une technique d’attaque de bout en bout : le mécanisme exact qui la rend possible, une démonstration reproductible menée sur un ouvrage construit pour l’occasion, et la contre-mesure qui la referme. Une page qui montre une attaque sans expliquer ce qu’elle contourne, ou sans dire comment s’en protéger, n’a pas sa place ici.
Un mécanicien apprend beaucoup en regardant un moteur casser sur un banc d’essai plutôt que sur l’autoroute. Cette rubrique fait la même chose avec les failles informatiques : chaque attaque y est rejouée dans un décor construit exprès, expliquée pas à pas, puis accompagnée du remède qui empêche de la reproduire ailleurs.
→ Lire l’explication complète de la marmotte
La plupart de ces articles paraissent sous la signature du Castor (construire un ouvrage, puis chercher méthodiquement par où il cède), mais une faille peut aussi être traitée par une autre voix quand le sujet l’exige : le principe reste le même, la signature s’adapte au registre du texte.
Une faille documentée ici reste rattachée à son domaine d’origine (cryptographie, réseaux, PKI) via les renvois internes de l’article : cette section ne duplique pas le contenu, elle rassemble les démonstrations d’attaque qui, ailleurs sur le site, resteraient noyées dans un chapitre plus large consacré au mécanisme qu’elles cassent.
Une organisation qui ne s’intéresse pas au détail des attaques corrige des symptômes : elle applique un correctif sans savoir quelle vérification manquait, et la même erreur réapparaît dans le code suivant sous un autre nom. Sans démonstration reproductible, une vulnérabilité signalée reste une opinion ; elle est classée comme théorique jusqu’au jour où quelqu’un d’autre prend la peine de la démontrer, en conditions réelles et sans prévenir. Les programmes de primes n’arrangent rien : la chasse aux primes ne paie que le premier rapport valide, et l’opinion du deuxième, même mieux démontrée, vaut exactement zéro euro. Les tests de non-régression n’ont alors rien à rejouer, et les équipes de détection ignorent quelle trace chercher, puisque personne n’a jamais regardé l’attaque se dérouler.
Une faille est un défaut qui permet à quelqu’un d’obtenir ce qu’il ne devrait pas : lire une donnée protégée, se faire passer pour un autre, prendre le contrôle d’une machine. Chaque article de cette rubrique suit le même ordre. Il décrit d’abord le mécanisme exact qui rend l’attaque possible : quelle règle est mal appliquée, quelle vérification manque, quelle information s’échappe. Il montre ensuite l’attaque en action, sur un système monté spécialement pour l’expérience, afin que chacun puisse refaire la démonstration sans toucher à un système réel. Il termine par la contre-mesure, c’est-à-dire la modification qui supprime la cause et empêche l’attaque de fonctionner. Un article qui montrerait une attaque sans expliquer ce qu’elle contourne, ou sans dire comment s’en protéger, n’est pas publié ici : la démonstration seule apprend à attaquer, pas à défendre. La plupart de ces textes sont signés par le Castor, la voix du site qui construit un système puis cherche méthodiquement par où il cède, mais une autre voix peut s’en charger quand le sujet l’exige. Chaque faille reste reliée par des renvois à la rubrique de son domaine d’origine, par exemple la cryptographie ou les réseaux : cette rubrique rassemble les démonstrations d’attaque sans recopier les explications de fond, qui restent dans les chapitres consacrés au mécanisme concerné.