Ce dépôt contient une application web volontairement vulnérable construite avec Next.js. Elle est conçue pour démontrer et étudier le problème de sécurité connu sous le nom de CVE-2025-29927. L'objectif de ce projet est d'aider les chercheurs en sécurité, les étudiants et les chasseurs de bugs à comprendre comment la vulnérabilité fonctionne dans un environnement réaliste.

[!CAUTION ] Cette application est intentionnellement non sécurisée et ne doit jamais être déployée en production.

🔩Objectif

• Apprendre comment la vulnérabilité fonctionne
• S'entraîner à l'identifier et à l'exploiter en toute sécurité
• Comprendre l'impact d'une gestion non sécurisée du middleware
• Améliorer ses compétences en bug bounty et en sécurité web

🐞Vulnérabilité

CVE-2025-29927 est liée à une gestion incorrecte de la logique des requêtes dans les applications construites avec Next.js, en particulier dans le middleware. Cela peut permettre aux attaquants de :

1. Contourner les contrôles d'authentification ou d'autorisation
2. Manipuler le flux des requêtes à l'aide d'en-têtes ou d'entrées forgés
3. Accéder à des ressources restreintes

📁Structure du projet

• app/ → Routes de l'application
• middleware.ts → Contient la logique vulnérable
• api/ → Points d'accès backend (y compris les routes protégées)

⚙️Installation et configuration

git clone https://github.com/metasploit403/cve-2025-29927-lab
cd cve-2025-29927-lab
npm install
npm run dev

🪲Points d'accès vulnérables

Certaines routes sont intentionnellement vulnérables et peuvent inclure :

- /api/admin/secret
- /api/internal/health
- /api/private/data

Ces points d'accès simulent des ressources restreintes qui ne devraient pas être accessibles sans autorisation appropriée.

🔥Exploitation

1. Supposons que vous ayez cloné le dépôt avec succès
2. Lancez npm run dev
3. Cela exécute votre projet localement
4. Ouvrez le navigateur de votre choix, par exemple Chrome, et tapez http://localhost:3000
5. Essayez d'accéder à l'un des 3 points d'accès API

- /api/admin/secret
- /api/internal/health
- /api/private/data

6. Essayez maintenant avec n'importe quel point d'accès

- http://localhost:3000/api/admin/secret
- http://localhost:3000/api/internal/health
- http://localhost:3000/api/private/data

7. Observez que votre requête est bloquée, car vous n'avez pas inclus de cookie dans votre requête. Cela signifie que le point d'accès est protégé par le middleware. Le middleware vérifie si votre requête contient un cookie et, si ce n'est pas le cas, elle est automatiquement bloquée.

8. Ajoutons maintenant un cookie à notre requête. Pour cela, ouvrez les outils de développement Chrome (j'utilise Chrome ici, vous pouvez utiliser n'importe quel navigateur)

9. Appuyez sur F12 et les outils de développement Chrome s'ouvriront

10. Allez dans l'onglet Console

11. Dans la console, tapez document.cookie="lab-auth=authenticated"

12. Rafraîchissez la page et observez que vous êtes connecté

Gardez à l'esprit que le middleware vérifie si la requête contient un cookie. Si la requête a un cookie, vous vous connectez avec succès ; sinon, vous êtes bloqué. La question est : COMMENT pouvons-nous contourner la vérification du middleware et nous connecter sans fournir de cookie ? C'est ce que CVE-2025-29927 nous permet de faire.

Maintenant, contournons la vérification d'authentification du middleware avec CVE-2025-29927. L'astuce consiste simplement à ajouter cet en-tête spécifique :
x-middleware-subrequest: middleware. Cet en-tête est censé être utilisé uniquement en interne par le Framework. Si nous l'ajoutons, le middleware cessera de vérifier si notre requête possède un cookie, et alors tout point d'accès sensible de votre application est sans défense.

Pour exploiter cela, utilisons cURL.
curl est un outil en ligne de commande utilisé pour envoyer des requêtes à un serveur et obtenir une réponse

1.Attendez-vous à un 401 sans cookie

curl.exe -i http://localhost:3000/api/admin/secret

Observez que le serveur a répondu avec le code d'état 307 redirection temporaire. Comme il n'y a pas de cookie, nous sommes redirigés vers la page d'accueil/la page racine. Cela signifie que nous ne pouvons pas nous connecter sans fournir de cookie.

2.curl.exe -i http://localhost:3000/api/admin/secret -H "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware"

Maintenant, nous avons ajouté "x-middleware-subrequest: middleware:middleware:middleware:middleware:middleware"
Observez que nous avons maintenant accès à la connexion sans le cookie. C'est un contournement complet de l'authentification.

🔐Mitigation

Pour corriger ce type de problèmes dans les applications réelles :

• Ne jamais faire aveuglément confiance aux en-têtes contrôlés par le client
• Valider toutes les entrées dans le middleware
• Implémenter des contrôles d'authentification appropriés côté serveur
• Éviter de se baser sur des hypothèses de requêtes non sécurisées
• Mettre à jour vers la version corrigée de Next.js
• Si vous ne pouvez pas mettre à jour, supprimez l'en-tête x-middleware-subrequest au niveau des reverse proxy

🫵À qui s'adresse ce projet ?

• Chasseurs de bugs
• Chercheurs en sécurité
• Étudiants apprenant la sécurité web
• Développeurs souhaitant comprendre la conception sécurisée de middleware

⛔Avertissement

Ce projet est uniquement à des fins éducatives. N'utilisez pas ces techniques sur des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de test.

🤝Contributions

N'hésitez pas à :

• Améliorer le laboratoire
• Ajouter de nouveaux scénarios vulnérables
• Soumettre des corrections ou de meilleures explications

⭐Soutien

Si vous trouvez cela utile, pensez à mettre une étoile sur le dépôt.

🏷️Tags

- Next.js 
- Bug Bounty 
- Web Security 
- CVE-2025-29927 
- Middleware Authentication 
- Bypass