← retour aux outils back to tools

# 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

2. 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