amulyakaushik/cve-2023-27163-labLabo basé sur Docker reproduisant la SSRF CVE-2023-27163 dans Request-Baskets, avec vérification de l'exploitation, script de détection et remédiation par isolation réseau.
Projet : Laboratoire de recherche et de reproduction de vulnérabilités — CVE-2023-27163
Auteur : Amulya Kaushik
Rôle : Candidat au stage en R&D cybersécurité et développement de contenu de laboratoire
Server-Side Request Forgery dans Request-Baskets ≤ 1.2.1
Un laboratoire de recherche local autonome pour reproduire, détecter et corriger CVE-2023-27163 avec une architecture de défense en profondeur.
| Champ | Valeur |
|---|
| ID CVE | CVE-2023-27163 |
| CWE | CWE-918 — Server-Side Request Forgery (SSRF) |
| Produit affecté | Request-Baskets |
| Versions affectées | ≤ 1.2.1 |
| Version corrigée | 1.2.2 (Source amont) / Isolation réseau de défense en profondeur |
| Score CVSS v3.1 | 6.5 (Moyen) |
| Vecteur CVSS | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| Complexité d'attaque | Faible — un seul appel API non authentifié |
Note sur les limitations amont et la remédiation :
Bien que CVE-2023-27163 concerne la validation d'URL de transfert arbitraire, les builds de conteneurs publics dedarklynx/request-basketsn'appliquent pas de filtrage loopback ou de sous-réseau privé par défaut. Suivant les meilleures pratiques DevSecOps du monde réel, notre laboratoire démontre la remédiation par isolation réseau de conteneurs en défense en profondeur. En isolant les backends internes sensibles sur un réseau Docker interne uniquement (secure-internal-netavecinternal: true), le chemin de relais est coupé, atténuant l'exploitabilité de la vulnérabilité SSRF même lors de l'exécution de forwarders de webhooks non fiables.
Ce laboratoire fournit deux topologies Docker Compose distinctes :
docker-compose.yml) : Request-Baskets et un service interne d'écho de secret partagent le réseau bridge lab-net. Request-Baskets est mappé sur le port hôte 55556 (mappé depuis le port conteneur 55555).docker-compose.patched.yml) : Request-Baskets est attaché exclusivement à public-net, tandis que le service d'écho interne est attaché à secure-internal-net (internal: true).docker-compose.yml)┌─────────────────────────────────────────────────────────┐
│ Docker: lab-net │
│ │
│ ┌─────────────────────┐ ┌────────────────────────┐ │
│ │ request-baskets │───▶│ internal-service │ │
│ │ (v1.2.1) │ │ (http-echo:5678) │ │
│ │ Port 55556 ◀──HOST │ │ NOT exposed to host │ │
│ └─────────────────────┘ └────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
▲
│ HTTP (port 55556)
│
┌────┴─────┐
│ Attacker │
└──────────┘
docker-compose.patched.yml)┌─────────────────────────┐ ┌─────────────────────────┐
│ public-net │ │ secure-internal-net │
│ │ │ (internal: true) │
│ ┌───────────────────┐ │ │ ┌───────────────────┐ │
│ │ request-baskets │ │ ✕ │ │ internal-service │ │
│ │ Port 55556◀─HOST │ │ ──/──▶ │ │ (http-echo:5678) │ │
│ └───────────────────┘ │ │ └───────────────────┘ │
└─────────────────────────┘ └─────────────────────────┘
| Exigence | Version minimale | Notes |
|---|---|---|
| Docker Engine | 20.10+ | Runtime de virtualisation de conteneurs |
| Docker Compose | v2.0+ | Orchestration multi-conteneurs |
| Python | 3.8+ | Outils de vérification et de détection en CLI |
Configuration de l'environnement virtuel Python et des dépendances :
python3 -m venv .venv
source .venv/bin/activate
pip install requests fpdf2
Démarrer l'environnement vulnérable (Request-Baskets v1.2.1 accessible à http://localhost:55556) :
docker compose up -d
Vérifier que les deux conteneurs sont en cours d'exécution :
docker compose ps
Sortie attendue :
NAME IMAGE COMMAND SERVICE STATUS PORTS
isolated-internal-service hashicorp/http-echo:latest "/http-echo -text=CO…" internal-service Up 5678/tcp
vulnerable-request-baskets darklynx/request-baskets:v1.2.1 "/bin/sh -c /bin/ent…" request-baskets Up 0.0.0.0:55556->55555/tcp
Confirmer que le service interne n'est pas directement accessible depuis l'hôte :
curl http://localhost:5678 2>&1 || echo "Connection refused — internal service isolated as expected"
Exécuter le script automatisé de vérification SSRF :
python3 scripts/verify_vulnerability.py
Ce qui se passe :
/api/baskets/ssrf-verification-basket en définissant forward_url: "http://internal-service:5678" et proxy_response: true.CONFIDENTIAL_DATA{INTERNAL_SSRF_DEMONSTRATION_SUCCESS} et affiche RESULT: VULNERABLE.Lancer la sonde d'audit non destructive :
python3 scripts/detect.py
Ce qui se passe :
http://127.0.0.1:80) est accepté.AUDIT RESULT: VULNERABLE en cas d'acceptation (HTTP 201) et nettoie le panier de sonde.Basculer vers la topologie corrigée segmentée :
docker compose down
docker compose -f docker-compose.patched.yml up -d
python3 scripts/verify_vulnerability.py
Sortie attendue :
==============================================================
[✓] REMEDIATION VERIFIED: TARGET SECURED
The Request-Baskets instance failed to reach the internal
isolated service (HTTP 502 / Host Unreachable).
Network segmentation successfully prevented SSRF data exfiltration.
==============================================================
Démonter l'environnement une fois terminé :
docker compose -f docker-compose.patched.yml down
Le portefeuille complet de preuves visuelles pour le Livrable 3 est maintenu dans le répertoire evidence/ :
| Artefact | Objectif | Lien du fichier | Description |
|---|---|---|---|
| Capture d'écran 1 | Environnement en cours d'exécution | 01_lab_running.png | Montre vulnerable-request-baskets (port 55556) et isolated-internal-service fonctionnant simultanément sur lab-net. |
| Capture d'écran 2 | Exploitation SSRF | 02_reproduction_ssrf.png | Affiche le drapeau CONFIDENTIAL_DATA{...} exfiltré et le statut VULNERABLE. |
| Capture d'écran 3 | Outil de détection défensive | 03_detection_tool_run.png | Affiche la vérification de signature en deux phases et l'audit loopback signalant VULNERABLE. |
| Capture d'écran 4 | Vérification de la remédiation | 04_remediation_verified.png | Prouve l'échec du relais (HTTP 502 / Host Unreachable) sous défense réseau segmentée. |
| Capture d'écran 5 | Configuration de l'interface web | 05_web_ui_ssrf.png | (Bonus) Capture navigateur des paramètres de l'interface Request-Baskets configurés avec Proxy Response. |
Les procédures détaillées, les commandes et les transcriptions de console pour chaque capture d'écran sont documentées dans evidence/README.md.
Pour capturer toutes les captures d'écran du terminal séquentiellement sans tracas de configuration manuelle, exécutez :
./scripts/capture_evidence_flow.sh
Compiler le rapport technique académique en PDF :
python3 docs/generate_blog_pdf.py
Sortie générée : docs/CVE-2023-27163-Technical-Blog.pdf
cve-2023-27163-lab/
├── .gitignore # Git artifact exclusions (.venv, cache, OS files)
├── docker-compose.yml # Vulnerable environment (shared lab-net, port 55556)
├── docker-compose.patched.yml # Remediated environment (disjoint network isolation)
├── README.md # Complete documentation, attribution & guide
├── scripts/
│ ├── capture_evidence_flow.sh # Interactive runner for capturing screenshots
│ ├── verify_vulnerability.py # SSRF exploitation & remediation verification CLI
│ └── detect.py # Defensive audit and detection tool
├── evidence/
│ └── README.md # Formal screenshot evidence walkthrough
└── docs/
├── technical_blog.md # Academic technical write-up (800–1,200 words)
├── generate_blog_pdf.py # Markdown → PDF converter
└── CVE-2023-27163-Technical-Blog.pdf # Compiled academic report PDF
Cette recherche et ce développement de laboratoire s'appuient sur des normes de sécurité ouvertes, des avis de fournisseurs et des bases de données de vulnérabilités :
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).Ce laboratoire est destiné à des fins éducatives et de recherche en sécurité autorisée uniquement. N'utilisez pas ces outils contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester.