retour aux outils back to tools Ducklings

XSRFProbe

Framework de scan et d'exploitation de vulnérabilités de cross-site request forgery qui détecte les jetons CSRF faibles ou manquants et génère des exploits PoC. Cross-site request forgery vulnerability scanning and exploitation framework that detects weak or missing CSRF tokens and generates PoC exploits.

↗ https://github.com/0xInfection/XSRFProbe

Overview

XSRFProbe automates CSRF (Cross-Site Request Forgery) discovery: it crawls a target, identifies forms and state-changing requests, checks whether anti-CSRF tokens are present and actually enforced (not just present-but-unvalidated), and generates ready-to-use HTML PoC exploits for confirmed findings — turning a normally manual “does this endpoint check the token” grind into an automated scan.

Common Usage

Basic scan against a target URL

xsrfprobe -u https://target.com

Crawl the whole site before testing discovered forms

xsrfprobe -u https://target.com --crawl

Authenticated scan using a cookie

xsrfprobe -u https://target.com -c "sessionid=abc123"

Skip PoC generation, just report findings

xsrfprobe -u https://target.com --skip-poc

Increase crawl depth

xsrfprobe -u https://target.com --crawl -D 3

Workflow

# 1. Authenticate manually and grab the session cookie

Run an authenticated crawl + scan

xsrfprobe -u https://target.com -c "sessionid=abc123" --crawl

# 3. Review generated PoC HTML files for confirmed vulnerable endpoints
#    (auto-submitting forms that replicate the state-changing request)

# 4. Host the PoC and demonstrate impact (e.g. change victim's email/password)

Tips

A present-but-unvalidated CSRF token (form has one, server never checks it) is exactly the class of bug XSRFProbe is built to catch — a manual “is there a token field” glance misses this.
Combine with a logged-in session cookie for meaningful results — most interesting CSRF targets sit behind authentication.
Always manually verify generated PoCs before reporting; automated CSRF detection can produce false positives on endpoints protected by other means (SameSite cookies, custom headers, Origin checks).

Help / Man page

usage: xsrfprobe [-h] -u URL [-c COOKIE] [--crawl] [-D DEPTH]
                  [--skip-poc] [-o OUTPUT] [-v]

optional arguments:
  -u URL          Target URL to scan
  -c COOKIE       Cookie header for authenticated scanning
  --crawl         Crawl the site to discover additional forms/endpoints
  -D DEPTH        Crawl depth (default: 2)
  --skip-poc      Skip generating HTML PoC exploits
  -o OUTPUT       Output directory for reports and PoCs
  -v, --verbose   Verbose output
  -h, --help      Show help and exit

Vue d’ensemble

XSRFProbe automatise la découverte de CSRF (Cross-Site Request Forgery) : il parcourt une cible, identifie les formulaires et requêtes changeant l’état, vérifie si des jetons anti-CSRF sont présents et réellement appliqués (pas seulement présents mais non validés), et génère des exploits PoC HTML prêts à l’emploi pour les découvertes confirmées : transformant en scan automatisé ce qui est normalement un travail manuel fastidieux consistant à vérifier si un endpoint contrôle le jeton.

Utilisation courante

# Scan basique sur une URL cible
xsrfprobe -u https://target.com

# Parcourir tout le site avant de tester les formulaires découverts
xsrfprobe -u https://target.com --crawl

# Scan authentifié avec un cookie
xsrfprobe -u https://target.com -c "sessionid=abc123"

# Ignorer la génération de PoC, ne signaler que les découvertes
xsrfprobe -u https://target.com --skip-poc

# Augmenter la profondeur de crawl
xsrfprobe -u https://target.com --crawl -D 3

Flux de travail

# 1. S'authentifier manuellement et récupérer le cookie de session

# 2. Lancer un crawl + scan authentifié
xsrfprobe -u https://target.com -c "sessionid=abc123" --crawl

# 3. Examiner les fichiers PoC HTML générés pour les endpoints vulnérables
#    confirmés (formulaires à auto-soumission reproduisant la requête
#    changeant l'état)

# 4. Héberger le PoC et démontrer l'impact (par ex. changer l'email/mot
#    de passe de la victime)

Conseils

Un jeton CSRF présent mais non validé (le formulaire en a un, le serveur ne le vérifie jamais) est exactement la classe de bug que XSRFProbe est conçu pour attraper : un simple coup d’œil manuel « y a-t-il un champ jeton » passe cela à côté.
Combiner avec un cookie de session authentifiée pour des résultats pertinents : la plupart des cibles CSRF intéressantes se trouvent derrière une authentification.
Toujours vérifier manuellement les PoC générés avant de les reporter ; la détection CSRF automatisée peut produire des faux positifs sur des endpoints protégés par d’autres moyens (cookies SameSite, en-têtes personnalisés, vérifications Origin).

Aide / Page de manuel

usage: xsrfprobe [-h] -u URL [-c COOKIE] [--crawl] [-D DEPTH]
                  [--skip-poc] [-o OUTPUT] [-v]

optional arguments:
  -u URL          Target URL to scan
  -c COOKIE       Cookie header for authenticated scanning
  --crawl         Crawl the site to discover additional forms/endpoints
  -D DEPTH        Crawl depth (default: 2)
  --skip-poc      Skip generating HTML PoC exploits
  -o OUTPUT       Output directory for reports and PoCs
  -v, --verbose   Verbose output
  -h, --help      Show help and exit