IDOR Vulnerability Testing
Tester les applications web pour les vulnérabilités IDOR
Également disponible depuis: zebbern
Identifier les vulnérabilités de référence directe d'objet non sécurisées qui permettent un accès non autorisé aux données utilisateur. Apprendre des méthodologies systématiques pour détecter les contournements de contrôle d'accès par la manipulation de paramètres et les techniques d'énumération.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "IDOR Vulnerability Testing". Tester example.com/api/profile?id=1001 pour les vulnérabilités IDOR
Résultat attendu:
Démarrage de l'évaluation de vulnérabilité IDOR...
Test 1 : Incrémenter/Décrémenter l'ID
Original : GET /api/profile?id=1001 → Retourne les données de user_1001
Modifié : GET /api/profile?id=1000 → Retourne les données de user_1000
VULNÉRABILITÉ CONFIRMÉE : Escalade de privilèges horizontale détectée. L'application retourne les données de profil d'autres utilisateurs sans vérifier la propriété.
Endpoints affectés :
- /api/profile?id={id}
- /api/user/{id}
Correction recommandée : Implémenter une vérification de propriété côté serveur comparant request.user.id avec l'id du profil demandé avant de retourner les données.
Utilisation de "IDOR Vulnerability Testing". Configurer Burp Suite Intruder pour énumérer les IDs de facture
Résultat attendu:
Configuration de Burp Suite Intruder :
1. Envoyer GET /api/invoice/123 à Intruder (Ctrl+I)
2. Définir la position du payload sur '123' dans l'URL
3. Type d'attaque : Sniper
4. Payloads :
- Type : Numbers
- From : 1
- To : 500
- Step : 1
5. Démarrer l'attaque
Guide d'analyse :
- Filtrer pour les codes statut 200 OK
- Vérifier le contenu de la réponse pour différentes données de facture
- Vérifier si des réponses 200 appartiennent à d'autres utilisateurs
- Rechercher les motifs 403/404 pour identifier les IDs valides vs invalides
Risque : Si les réponses 200 retournent les données de facture d'autres utilisateurs, il s'agit d'une vulnérabilité IDOR critique exposant des informations financières sensibles.
Utilisation de "IDOR Vulnerability Testing". Générer du code de correction pour la vulnérabilité IDOR découverte
Résultat attendu:
CORRECTION : Adresser l'IDOR de mise à jour
Code vulnérable actuel :
def update_address(request, address_id):
address = Address.objects.get(id=address_id)
address.update(request.data) # Aucune vérification de propriété !
Implémentation sécurisée :
Option 1 - Validation de propriété :
```python
def update_address(request, address_id):
address = get_object_or_404(Address, id=address_id)
if address.user_id != request.user.id:
return HttpResponseForbidden('Unauthorized')
address.update(request.data)
return JsonResponse({'status': 'success'})
```
Option 2 - Modèle de référence indirecte :
```python
def update_address(request):
# Toujours filtrer par utilisateur authentifié
address = get_object_or_404(Address, user=request.user)
address.update(request.data)
return JsonResponse({'status': 'success'})
```
Recommandation : Utiliser l'Option 2 (références indirectes) car elle prévient les IDOR par conception plutôt que de s'appuyer sur des vérifications de validation.
Audit de sécurité
Risque faibleStatic analysis detected 80 external command patterns flagged as Ruby/shell backtick execution. After evaluation, all findings are FALSE POSITIVES - the backticks appear exclusively in Markdown code blocks as educational examples demonstrating IDOR vulnerability testing techniques. The skill provides legitimate security testing guidance for authorized penetration testing activities. No actual executable code or command injection risks present.
Problèmes à risque faible (1)
Facteurs de risque
⚙️ Commandes externes (80)
Score de qualité
Ce que vous pouvez construire
Tests d'intrusion d'applications web
Les professionnels de la sécurité effectuent des tests d'intrusion autorisés pour identifier les vulnérabilités IDOR dans les applications clientes avant que des acteurs malveillants ne les découvrent
Audits de sécurité d'applications
Les équipes de développement valident les implémentations de contrôle d'accès lors des revues de sécurité ou dans le cadre des processus de cycle de développement sécurisé
Chasse aux bugs (Bug Bounty)
Les chercheurs indépendants testent systématiquement les applications pour détecter les failles IDOR afin de gagner des récompenses via des programmes de divulgation responsable
Essayez ces prompts
Testez l'application sur example.com pour les vulnérabilités IDOR. J'ai deux comptes utilisateurs (user1@test.com et user2@test.com). Guidez-moi à travers le processus de vérification si je peux accéder aux données de user2 tout en étant authentifié en tant que user1.
Aidez-moi à configurer Burp Suite Intruder pour tester les endpoints /api/user/{id} et /api/order/{orderId} pour les vulnérabilités IDOR. Configurez une attaque sniper avec des payloads numériques de 1 à 1000 et montrez-moi comment analyser les résultats.Les requêtes GET vers /api/admin/users/{id} retournent 403 Forbidden. Montrez-moi comment tester les IDOR en utilisant le changement de méthode HTTP (POST, PUT, PATCH) et les techniques de pollution de paramètres pour contourner les contrôles d'accès.J'ai trouvé une vulnérabilité IDOR dans /download/receipt_{id}.pdf où je peux accéder aux reçus d'autres utilisateurs. Générez un rapport de preuve de concept et fournissez des exemples de code Python montrant une implémentation appropriée des contrôles d'accès pour corriger ce problème.Bonnes pratiques
- Toujours obtenir une autorisation écrite avant d'effectuer des tests IDOR sur des systèmes de production. Documenter toutes les activités de test et les découvertes pour un rapport approprié.
- Créer des comptes de test dédiés pour l'évaluation de sécurité plutôt que d'utiliser des données utilisateur réelles. Utiliser des données clairement identifiables (par ex. 'IDOR_TEST_USER') pour vérifier l'accès sans exposer d'informations personnelles réelles.
- Combiner plusieurs techniques de test : manipulation de paramètres, changement de méthode HTTP et énumération automatisée. Certaines vulnérabilités IDOR ne se manifestent que par des motifs de requête spécifiques.
Éviter
- Ne jamais tester les vulnérabilités IDOR sur des applications sans autorisation explicite. Les tests de contrôle d'accès non autorisés sont illégaux et violent les lois sur la fraude informatique.
- Éviter de modifier ou supprimer des données pendant les tests IDOR. Effectuer uniquement des opérations de lecture pour vérifier l'existence de la vulnérabilité. La modification de données peut causer des problèmes de production et une responsabilité légale.
- Ne pas supposer que les identifiants aléatoires (UUID/GUID) empêchent les IDOR. Les UUID peuvent parfois être énumérés via les réponses API, les fichiers JavaScript ou les algorithmes de prédiction basés sur le temps.
Foire aux questions
Qu'est-ce qu'une vulnérabilité IDOR ?
Cette compétence est-elle uniquement pour les professionnels de la sécurité ?
Ai-je besoin de Burp Suite pour utiliser cette compétence ?
Cette compétence peut-elle détecter tous les types de vulnérabilités IDOR ?
Est-il légal de tester des applications pour les vulnérabilités IDOR ?
Que dois-je faire si je trouve une vulnérabilité IDOR ?
Détails du développeur
Auteur
sickn33Licence
MIT
Dépôt
https://github.com/sickn33/antigravity-awesome-skills/tree/main/web-app/public/skills/idor-testingRéf
main
Structure de fichiers
📄 SKILL.md