Skip to content

Rapport exemple · Scénarios fictifs

Ce qu’un attaquant pourrait atteindre, et comment l’en empêcher

Ces reconstitutions fictives s’inspirent de types de failles réels. Domaines, comptes, réponses et historiques de tests sont inventés. Ce ne sont ni des résultats clients ni la preuve qu’EverBreach a effectué ces tests.

Les points à traiter

Dans le portail de recrutement, un compte candidat ordinaire peut lire les données et le CV d’un autre candidat. Dans la boutique photo, un visiteur peut récupérer une image en pleine résolution sans payer. Les deux défauts se situent côté serveur. Masquer un bouton ne bloque pas ces accès.

  1. Haute · Limiter immédiatement l’accès

    Un compte candidat peut lire les dossiers d’autres candidats

    Équipe responsable: Équipe applicative et responsable du recrutement

    Restreindre les listes de candidatures et les téléchargements de CV pendant la correction des autorisations.

  2. Haute · Fermer l’accès sans paiement

    Les photos originales sont accessibles avant le paiement

    Équipe responsable: Équipe e-commerce et responsable stockage/CDN

    Rendre les originaux privés et ne plus fournir de liens utilisables aux visiteurs qui n’ont pas payé.

Ce que couvre cet exemple

Deux environnements distincts : un portail de recrutement et une boutique photo. Les tests utilisent des candidatures créées pour l’essai, des CV fictifs, des images de test et des comptes aux rôles convenus. Aucune donnée de vrai candidat ni aucun contenu payant n’est consulté.

Haute · Limiter immédiatement l’accès

1. Un compte candidat peut lire les dossiers d’autres candidats

Équipe responsable
Équipe applicative et responsable du recrutement
Mesure immédiate
Restreindre les listes de candidatures et les téléchargements de CV pendant la correction des autorisations.

Conséquences pour l’organisation

Noms, coordonnées et CV peuvent révéler un parcours professionnel et d’autres informations personnelles. Un attaquant pourrait les utiliser pour une fraude ciblée ou les publier. Si le même contrôle manque pour tout le recrutement en cours, toutes les nouvelles candidatures pourraient être concernées. Le test limité ci-dessous ne démontre pas cette étendue.

Ce qui a été démontré

Le compte A a reçu les candidatures de test A et B et téléchargé le CV fictif de B. Sans connexion, la réponse était 401. Le défaut porte sur les droits d’un utilisateur connecté ; la connexion n’a pas été contournée. Le test s’est arrêté après les deux dossiers convenus.

Comment un attaquant pourrait procéder

  1. Créer ou utiliser un compte candidat ordinaire, sans droits de recruteur.
  2. Demander la liste utilisée par le portail. Le serveur renvoie le dossier d’un autre candidat en plus de celui du compte.
  3. Utiliser l’identifiant reçu pour demander le CV de cet autre candidat. Répéter l’opération pourrait élargir l’exposition. Aucune collecte massive n’a été réalisée.

Pourquoi ce test a révélé le problème

Déclencheur fictif : une nouvelle version de l’application. Avec le même compte et les mêmes données, la liste répondait 403 en r41, puis 200 en r42. Dans cette reconstitution, la comparaison du code révèle une nouvelle route sans contrôle du rôle de recruteur. Le modèle et le dispositif de test n’ont pas changé ; la modification applicative est déterminante.

Preuves et corrections

Environnement d’exemple: careers.example.com · version r42

Exemple de requête et de réponse

GET /api/applications?status=new
Session: applicant_test_A (no recruiter role)
HTTP 200
[{id:"test-A", email:"a@example.com"},
 {id:"test-B", email:"b@example.com"}]

GET /api/applications/test-B/cv
Session: applicant_test_A
HTTP 200 · application/pdf (synthetic CV)

Control: no session -> HTTP 401

Pourquoi cet accès était possible

La route de liste vérifie seulement la présence d’une session valide. Elle n’exige pas le rôle de recruteur et ne limite pas les dossiers à leur propriétaire. La route des CV omet aussi le contrôle par objet. Des identifiants difficiles à deviner ne suffiraient pas : la liste les révèle déjà.

Corriger la cause du problème

  1. Refuser temporairement l’accès des candidats aux routes de liste et de documents. Conserver les journaux utiles et établir depuis quand la version concernée était accessible.
  2. Réserver les listes générales aux recruteurs autorisés, côté serveur. Limiter chaque candidat à ses propres données autorisées. Appliquer la même règle aux CV et à l’accès direct au stockage.
  3. Ajouter des tests avec A, B, un recruteur autorisé et sans session. Couvrir listes, détails, exports et pièces jointes ; refuser par défaut.
  4. Examiner les journaux à la recherche d’accès non autorisés et associer les responsables des incidents et de la protection des données à l’évaluation d’une exposition réelle. Ne pas copier de données personnelles dans des tickets ordinaires.

Critères de validation après correction

A conserve les fonctions prévues pour ses propres données, mais reçoit 403 ou 404 sans contenu pour le dossier et le CV de B. La liste refuse les comptes candidats. Les recruteurs autorisés conservent leurs accès ; les requêtes anonymes échouent, ainsi que l’accès direct aux fichiers. Conserver ces cas dans les tests de non-régression.

Démontré dans l’exemple : accès à deux dossiers de test et à un CV fictif appartenant à un autre compte. Non établi : accès à tous les candidats, abus passé ou exposition d’une base de production.

OWASP · Autorisation au niveau de l’objet

Haute · Fermer l’accès sans paiement

2. Les photos originales sont accessibles avant le paiement

Équipe responsable
Équipe e-commerce et responsable stockage/CDN
Mesure immédiate
Rendre les originaux privés et ne plus fournir de liens utilisables aux visiteurs qui n’ont pas payé.

Conséquences pour l’organisation

La boutique livre le produit avant la fin de la vente. Un visiteur pourrait conserver ou redistribuer l’original sans l’acheter. Si les autres articles utilisent les mêmes réponses et règles de stockage, de nombreuses images pourraient être concernées. L’exemple démontre l’accès à une image de test convenue, pas au catalogue entier.

Ce qui a été démontré

Un compte acheteur sans achat a reçu l’URL de l’original dans la réponse photo. Une requête séparée sans session a récupéré l’image de test en pleine résolution. La commande est restée impayée et aucun paiement n’a été effectué.

Comment un attaquant pourrait procéder

  1. Ouvrir la page d’achat d’une photo sans l’avoir achetée.
  2. Lire les informations envoyées au navigateur avant le paiement. Elles contiennent l’adresse de l’original, même si la page ne montre qu’un aperçu.
  3. Demander directement cette adresse. Le serveur de fichiers livre l’original sans vérifier l’achat. D’autres images devraient être testées avant de conclure à un accès à tout le catalogue.

Pourquoi ce test a révélé le problème

Déclencheur fictif : un nouveau test après un changement de modèle. Version r17, comptes, données, outils, instructions et budget restent identiques. Le second essai suit le lien de l’aperçu à l’original ; le précédent n’avait rien signalé. La faille existait déjà. Deux essais isolés ne prouvent pas que le nouveau modèle explique l’amélioration ; il faudrait des essais comparables répétés.

Preuves et corrections

Environnement d’exemple: studio.example.com + media.example.com · version r17

Exemple de requête et de réponse

GET /api/photos/test-photo-01
Session: buyer_test_A · purchases: []
HTTP 200
{"previewUrl":"/previews/test-photo-01.jpg",
 "originalUrl":"https://media.example.com/originals/test-photo-01.jpg"}

GET originalUrl · no session
HTTP 200 · image/jpeg · full resolution
Order state: unpaid · no payment submitted

Pourquoi cet accès était possible

L’interface masque le bouton de téléchargement jusqu’au paiement, mais l’API révèle l’URL en amont et le serveur de fichiers la rend publique. Deux contrôles manquent : le droit lié à l’achat dans l’application et l’accès privé à l’origine des fichiers.

Corriger la cause du problème

  1. Fermer l’accès public aux originaux dans le stockage et le CDN. Invalider les copies publiques en cache et les anciens liens d’accès lorsque c’est applicable. Garder les aperçus disponibles.
  2. Fournir des aperçus avant achat. Avant de donner accès à un original, confirmer le paiement côté serveur auprès du prestataire et vérifier le droit de cet acheteur sur cette image. Ne pas se fier à une page de succès ou à un statut transmis par le navigateur.
  3. Servir les originaux via une route qui contrôle les droits, ou émettre ensuite des URL signées de courte durée limitées au fichier. Toute personne possédant un tel lien peut l’utiliser jusqu’à expiration ; ne jamais le fournir avant paiement.
  4. Tester les paiements absents, en attente, échoués ou annulés, un achat valide et l’accès à une autre image. Vérifier que le serveur de fichiers ne contourne pas la décision applicative.

Critères de validation après correction

Sans achat, la réponse ne contient qu’un aperçu et aucun lien utilisable vers l’original. L’accès direct échoue. Un paiement en attente, échoué ou annulé n’ouvre aucun accès. Un acheteur confirmé peut télécharger uniquement l’image achetée. Les liens expirés échouent et les aperçus publics fonctionnent toujours.

Démontré dans l’exemple : un original de test récupéré sans paiement. Non établi : accès à toutes les images, ventes réellement perdues ou avantage propre à un modèle.

OWASP · Autorisation des transactions

Transformer les résultats en tâches attribuées

Exemple de message pour une équipe interne ou un prestataire. Reprenez uniquement les points qui concernent votre système et joignez le vrai rapport.

Bonjour, Merci d’examiner les résultats joints et de désigner un responsable pour chaque problème concerné. RECRUTEMENT : réserver les listes aux recruteurs autorisés et contrôler les droits sur chaque candidature et téléchargement de CV. Conserver les journaux utiles et examiner la période d’exposition possible. BOUTIQUE PHOTO : rendre les originaux privés. Autoriser le téléchargement seulement après confirmation du paiement côté serveur et vérification du droit sur cette image précise. Contrôler le stockage et le CDN. Merci de confirmer les mesures immédiates, la correction durable, le coût et la date prévue avant réalisation. Intégrer les cas d’accès autorisés et refusés du rapport aux tests de non-régression, puis prévoir une nouvelle vérification. Merci.

Ce que ce rapport ne permet pas de conclure

Ces scénarios illustrent la profondeur d’une analyse applicative, pas la couverture du scanner externe actuel. Un mandat réel doit préciser séparément les accès, comptes de test, actions autorisées et critères d’arrêt. Les exemples démontrent des accès limités à des données de test. Ils ne prouvent ni une intrusion réelle, ni une exposition totale, ni le taux de réussite général d’un modèle d’IA.

Voir ce que comprend l’analyseDemander une analyse pilote