Trouver les failles courantes

Quelques classes de vulnérabilités rapportent la plupart des primes, car elles sont courantes et ont un impact important. Commencez par maîtriser ces trois catégories :

• IDOR — accéder aux données d’autres utilisateurs au moyen d’identifiants prévisibles
• XSS — injecter un script dans une page
• SSRF — amener le serveur à récupérer des URL choisies par l’attaquant

Cette leçon vous montre comment rechercher chacune d’elles méthodiquement.

Une référence directe d’objet non sécurisée (IDOR) se produit lorsqu’une application utilise un identifiant fourni par l’utilisateur pour récupérer un objet sans vérifier que cet utilisateur en est le propriétaire.

Modifiez l’ID et accédez aux données de quelqu’un d’autre. Il s’agit d’une faille de contrôle d’accès, et non d’une injection.

Pour trouver une IDOR, créez deux comptes et comparez-les. Tout ce qui fait référence à un objet par son ID est un candidat potentiel.

• Capturez une requête du compte A qui récupère les données de A
• Rejouez-la avec la session du compte B, mais avec l’ID de l’objet de A
• Si B voit les données de A, il s’agit d’une IDOR

Recherchez les ID dans les URL, les corps JSON, les en-têtes et même sous forme de base64 ou d’UUID.

Le Cross-Site Scripting (XSS) consiste à injecter du JavaScript qui s’exécute dans le navigateur d’un autre utilisateur. Il existe trois principaux types :

• Réfléchi — la charge utile est renvoyée dans la réponse immédiate
• Stocké — la charge utile est enregistrée puis transmise à d’autres utilisateurs (impact maximal)
• Basé sur le DOM — le JS côté client écrit de manière non sécurisée une entrée contrôlée par l’attaquant dans le DOM

Injectez d’abord un marqueur unique pour voir où et comment votre entrée est réfléchie, puis concevez une charge utile adaptée au contexte (corps HTML, attribut ou script).

Le contexte détermine quelle charge utile permet de sortir du contexte et de s’exécuter.

Un simple alert(1) prouve l’exécution, mais les évaluateurs veulent connaître l’impact. Démontrez ce qu’un attaquant pourrait réellement dérober ou faire.

• Lisez un jeton CSRF ou des informations de session accessibles au JS
• Montrez document.domain pour prouver l’origine
• Pour une XSS stockée, montrez son exécution dans le compte d’une victime

Ne dérobez jamais réellement les sessions d’utilisateurs ; démontrez simplement cette possibilité.

Dans le contexte des primes de sécurité, une SSRF consiste à trouver une fonctionnalité qui récupère une URL que vous contrôlez. Les candidats probables sont les suivants :

• URL de webhooks et URL de rappel
• Générateurs d’images ou de PDF qui récupèrent des ressources distantes
• Fonctionnalités d’aperçu d’URL ou de déploiement automatique de liens
• Fonctionnalités d’importation depuis une URL

Faites pointer ces fonctionnalités vers des points de terminaison internes ou de métadonnées pour démontrer l’impact.

Lorsque la réponse n’affiche pas le contenu récupéré, utilisez un serveur hors bande pour confirmer que la cible a effectué une requête. Un rappel d’interaction prouve une SSRF aveugle.

Des outils comme Burp Collaborator ou interactsh vous fournissent une URL unique qui journalise les accès.

Les trois classes de vulnérabilités se trouvent en interceptant et en modifiant les requêtes. Un proxy d’interception est l’outil essentiel.

• Burp Suite ou OWASP ZAP pour capturer et modifier le trafic
• Repeater pour rejouer et ajuster des requêtes individuelles
• Intruder/fuzzer pour tester de nombreux ID ou charges utiles

Approfondir la maîtrise de votre proxy vous sera plus utile que n’importe quelle technique isolée.

Les primes les plus élevées proviennent de l’enchaînement de vulnérabilités. Une vulnérabilité de gravité moyenne combinée à une autre peut devenir critique.

• Une SSRF atteignant les métadonnées du cloud peut conduire au vol d’identifiants et à la prise de contrôle d’un compte
• Une IDOR exposant des jetons peut conduire à la compromission complète d’un compte
• Une XSS stockée dans un panneau d’administration peut conduire à la prise de contrôle du compte administrateur

Demandez-vous toujours : à quoi cette vulnérabilité peut-elle être combinée ?

Ces vulnérabilités touchent des données et des utilisateurs réels. Restez éthique :

• Utilisez vos propres comptes de test et ne consultez pas les données d’utilisateurs réels au-delà de ce qui est nécessaire pour prouver le problème
• Évitez les charges utiles XSS stockées qui pourraient s’exécuter pour de vrais utilisateurs ; limitez-les à votre propre compte
• Pour une SSRF, ne progressez pas en profondeur dans les systèmes internes ; prouvez le mécanisme élémentaire, puis arrêtez-vous

Démontrer l’impact de manière responsable vous permet de rester couvert par la clause de sécurité.

Vous vous connectez en tant qu’utilisateur B, rejouez une requête avec la session de B mais avec l’ID d’objet de l’utilisateur A, et recevez les données privées de A. De quelle vulnérabilité s’agit-il ?

Vous avez appris à rechercher les trois classes de vulnérabilités les plus précieuses.

• IDOR : comparez deux comptes, modifiez les ID d’objet et vérifiez l’application du contrôle de propriété
• XSS : sondez la réflexion, adaptez la charge utile au contexte et prouvez l’impact réel
• SSRF : trouvez les fonctionnalités qui récupèrent des URL et confirmez les cas aveugles hors bande
• Enchaînez les vulnérabilités pour obtenir un impact critique (par exemple, une SSRF vers les métadonnées du cloud)
• Utilisez un proxy d’interception et restez dans le périmètre

Ensuite : transformer vos découvertes en rapports récompensés.