
de security-skill19
Envoyez des rafales de requêtes concurrentes pour détecter les TOCTOU, la réutilisation de coupons, le double paiement et d'autres conditions de concurrence sur les endpoints web.
Cette compétence fournit un flux de travail pratique pour tester les endpoints web pour les vulnérabilités de condition de concurrence en lançant des requêtes concurrentes contrôlées contre des opérations avec état (utilisation de coupon, débit de solde, passation de commande, vérification OTP). Elle guide l'agent dans l'identification des cibles probables, la création de payloads de requêtes, l'exécution de rafales synchronisées (via curl + GNU parallel) et l'analyse des modèles de réponse et de l'état du serveur pour déterminer si plusieurs requêtes ont été acceptées par erreur.
Utilisez cette compétence lors d'évaluations de sécurité, de triage de bug-bounty ou de QA lorsque vous soupçonnez des opérations non atomiques : utilisation de codes promo, dépenses de crédits cadeaux, décrémentation d'inventaire lors d'un achat, vérification OTP/token, ou actions sensibles limitées par le débit. Elle aide à confirmer les faiblesses TOCTOU, le double paiement et le dépassement de limite.
Idéal pour les agents pouvant exécuter des commandes shell ou fournir des conseils pour les flux de travail de pentesting (agents avec outils bash/CLI, assistants axés sur la sécurité).
Une compétence de test de sécurité pour détecter les vulnérabilités de race condition (TOCTOU, réutilisation de coupons, double dépense) via des rafales de requêtes HTTP concurrentes utilisant curl et GNU parallel. Bien documentée avec des étapes claires, un tableau d'entrées, des modes d'échec et une classification d'impact. Aucun script groupé — toutes les instructions sont en bash inline dans SKILL.md. Outil légitime de pentest/bug-bounty avec un risque d'injection shell dans l'interpolation des variables mais sans intention malveillante.
Compétence de test axée sur la sécurité pour un usage légitime. La technique de requêtes concurrentes est standard pour le test de race condition. Le risque d'injection shell est modéré car l'utilisateur contrôle les variables d'entrée. Pas d'exfiltration, pas de phone-home, pas de commandes destructrices. Documentation bien écrite avec une bonne couverture des modes d'échec et de l'évaluation d'impact.