Défis Web et de cryptographie

Les applications web et la cryptographie sont les deux points d'entrée les plus courants dans les CTF.

• Les défis d'applications web vous fournissent une application web en fonctionnement et vous demandent de trouver une faille dans sa gestion des saisies, de l'authentification ou de la confiance.
• Les défis de cryptographie vous fournissent un texte chiffré, un schéma et parfois du code source, puis vous demandent de retrouver le texte en clair ou une clé en exploitant une faille dans l'utilisation de la cryptographie.

Les deux formats récompensent une observation méthodique. Cette leçon présente les énigmes récurrentes de chacun.

Avant toute exploitation, cartographiez l'application. Consultez le code source, examinez les réponses et explorez le contenu dissimulé.

L'injection SQL se produit lorsque la saisie utilisateur est concaténée à une requête de base de données sans séparation entre le code et les données.

Un formulaire de connexion qui construit une requête comme SELECT * FROM users WHERE name='INPUT' peut être détourné par une saisie qui ferme la chaîne et modifie la logique :

Les CTF vous apprennent à casser les injections afin de savoir les défendre. La bonne défense consiste à utiliser des requêtes paramétrées (des instructions préparées), qui maintiennent entièrement les données utilisateur en dehors de la structure de la requête.

Le XSS se produit lorsqu'une application réaffiche ou stocke une saisie contrôlée par l'attaquant et qu'un navigateur l'exécute comme un script. Dans un CTF, un défi XSS implique souvent un robot qui visite votre charge utile tout en conservant le drapeau dans un cookie.

• Réfléchi — la charge utile incluse dans la requête est renvoyée directement.
• Stocké — la charge utile est enregistrée et s'exécute pour les visiteurs suivants.
• Fondé sur le DOM — le JavaScript côté client écrit la saisie dans la page de manière dangereuse.

La défense consiste à encoder les sorties en fonction du contexte et à appliquer une politique de sécurité du contenu. Un test exploratoire comme <script>alert(1)</script> confirme si la saisie est échappée.

Voici deux autres incontournables du web :

• Server-Side Request Forgery (SSRF) — vous amenez le serveur à effectuer des requêtes à votre place, souvent vers des adresses accessibles uniquement en interne comme http://127.0.0.1 ou vers un service de métadonnées infonuagique, afin d'atteindre le drapeau.
• Traversée de répertoires — vous sortez du répertoire prévu à l'aide de séquences comme ../ pour lire des fichiers situés en dehors de la racine web, par exemple ../../../../etc/passwd.

Ces deux attaques résultent de la confiance accordée à la saisie utilisateur pour choisir une ressource. Les défenses consistent à utiliser des listes d'autorisation strictes, puis à canonicaliser et valider les chemins avant leur utilisation.

Le piège cryptographique le plus courant chez les débutants consiste à confondre encodage et chiffrement. L'encodage est réversible par n'importe qui, sans clé : il n'offre donc aucune confidentialité.

Apprenez à reconnaître les formats au premier regard :

• Base64 — des lettres, des chiffres, + / et souvent un remplissage avec =.
• Hexadécimal — uniquement 0-9 a-f.
• ROT13 / César — une structure lisible avec des lettres décalées.

De nombreux défis de cryptographie utilisent des chiffres historiques faibles ou des chiffres modernes mal conçus :

• César / Vigenère — des chiffres par décalage que l'on casse par analyse des fréquences ou en essayant les 25 décalages.
• XOR sur un seul octet — le message entier est soumis à XOR avec un seul octet : essayez par force brute les 256 clés et retenez la sortie lisible.
• XOR à clé répétée — on le casse en trouvant la longueur de la clé, puis en résolvant chaque octet de clé comme un XOR sur un seul octet.

La leçon à retenir : un chiffre personnalisé ou classique n'offre aucune véritable sécurité contre un analyste.

RSA n'est sûr que lorsque ses paramètres sont correctement choisis. Les défis de cryptographie des CTF aiment vous fournir une instance défectueuse :

• Petit module — si n est suffisamment petit, factorisez-le directement pour retrouver la clé privée.
• Exposant minuscule, sans bourrage — avec e=3 et un message court, le texte chiffré peut être un cube parfait, récupérable par une racine cubique entière.
• Facteurs communs — si deux clés publiques partagent un nombre premier, le plus grand commun diviseur de leurs modules le révèle instantanément.

Dans le monde réel, la défense consiste à utiliser une bibliothèque éprouvée avec de grandes clés et un bourrage approprié (OAEP), et à ne jamais implémenter soi-même son propre système.

Lorsqu’un défi vous fournit le hachage d’un mot de passe, l’objectif est de retrouver la donnée d’origine. Vous ne pouvez pas inverser un hachage, mais vous pouvez essayer des entrées et les comparer.

Reliez le tout au moyen d’une boucle cohérente pour les deux catégories :

• Observez — lisez l’énoncé, consultez le code source, identifiez l’encodage ou le schéma.
• Formulez une hypothèse — nommez la famille de vulnérabilités probable.
• Testez à petite échelle — envoyez une charge utile de sondage, observez la réponse exacte.
• Exploitez — transformez la sonde qui fonctionne en une charge utile complète permettant d’obtenir le drapeau.
• Documentez — notez la charge utile et le raisonnement tant qu’ils sont encore frais.

Cette boucle vous évite de vous perdre dans des fausses pistes et produit presque gratuitement un compte rendu.

Évaluez votre maîtrise des principes fondamentaux du Web et de la cryptographie.

Vous avez étudié les énigmes récurrentes du Web et de la cryptographie :

• Web : commencez par cartographier, puis recherchez une injection SQL, une vulnérabilité XSS, une SSRF et une traversée de chemin — chacune reposant sur une confiance excessive et dangereuse accordée aux entrées utilisateur, et chacune se corrigeant en séparant le code des données.
• Cryptographie : distinguez l’encodage du chiffrement, cassez les chiffres classiques et XOR, exploitez les erreurs de paramètres RSA et craquez les hachages avec des listes de mots.
• Une seule boucle observer, formuler une hypothèse, tester, exploiter, documenter fonctionne pour les deux.

Ensuite, vous passez à la rétro-ingénierie et à l’exploitation binaire.