Ravage

Ravage è una CLI evidence-first per valutare un'applicazione web in esecuzione di cui sei proprietario o che sei esplicitamente autorizzato a testare. Combina ricognizione deterministica e validazione con un ciclo di attacco opzionale guidato da modelli, mantenendo scope, autenticazione, contabilità del traffico ed evidenze entro confini definiti dal codice.

Ravage è un'alpha di ricerca pre-1.0. Usa ambienti usa e getta e regole di ingaggio scritte. I test di sicurezza possono modificare lo stato dell'applicazione; Ravage non corregge i risultati né implementa fix.

Avvio rapido · Autenticazione · Risultati · Funzionalità · Documentazione

Requisiti

• Python 3.12
• Git
• macOS, Linux o WSL
• Docker solo per strumenti containerizzati, XBEN e test di integrazione
• Una chiave API del provider solo per i comandi guidati da modelli

La prima scansione normale non richiede chiave del modello, browser, daemon Docker o scanner esterno.

Installazione dal sorgente

git clone https://github.com/duriantaco/ravage.git
cd ravage
scripts/bootstrap.sh
source .venv/bin/activate
ravage doctor

Il bootstrap crea .venv e installa il workspace. Usa scripts/bootstrap.sh --dev per le dipendenze di sviluppo, --browser per il supporto browser, oppure --install-browser per installare anche Chromium.

Avvio rapido locale in cinque minuti

Avvia prima la tua applicazione. Questo esempio presuppone che sia in ascolto su http://127.0.0.1:3000.

1. Crea un brief di ingaggio con scope definito e un file di ambiente privato:

   root@kitploit:~

   ravage init http://127.0.0.1:3000 \
     --brief ravage-brief.yaml \
     --env-file .env.ravage \
     --description "Valutazione autorizzata della mia app di sviluppo locale."
   

2. Rivedi ravage-brief.yaml. Controlla il target, le route in scope, le esclusioni, il budget di richieste, il rate limit, gli obiettivi e i criteri di successo.

3. Esegui una scansione superficiale senza modello:

   root@kitploit:~

   ravage doctor --workflow scan --brief ravage-brief.yaml
   ravage scan ravage-brief.yaml --probe surface_map --report
   

Il comando stampa la directory di esecuzione. Copia quel percorso e usalo come RUN_DIR nei comandi di ispezione qui sotto.

Esegui l'agente guidato da modelli

Aggiungi una chiave di un provider supportato, ad esempio OPENAI_API_KEY, a .env.ravage. Ravage legge questo file direttamente; non eseguirne il source nella shell.

ravage doctor --workflow attack --brief ravage-brief.yaml
ravage attack ravage-brief.yaml --allow-paid-models --report

--allow-paid-models è una conferma esplicita che l'esecuzione può comportare costi del provider. La selezione dei modelli, i provider locali e i profili riproducibili sono documentati in Provider di modelli.

Test autenticati

Aggiungi un'identità di test dedicata al brief:

ravage auth add ravage-brief.yaml \
  --identity user \
  --type form \
  --login /login \
  --health /account \
  --marker Logout \
  --env-file .env.ravage

Compila i riferimenti ai segreti generati, verifica la sessione, poi attacca con l'identità selezionata:

ravage auth check ravage-brief.yaml --identity user
ravage attack ravage-brief.yaml \
  --identity user \
  --allow-paid-models \
  --report

Sono supportati il login tramite form, i bearer token e gli header statici fissi. Le credenziali gestite restano all'interno del proprietario HTTP autenticato; i canali di processo, Python e comando vengono bloccati quando viene selezionata un'identità. Vedi Autenticazione per configurazione e limitazioni.

Target remoti autorizzati

L'esecuzione remota è fail-closed e richiede un flag esplicito. Inizia con una scansione superficiale a basso impatto:

ravage init https://staging.example.test \
  --brief ravage-brief.yaml \
  --env-file .env.ravage \
  --description "Valutazione autorizzata della mia applicazione di staging."

ravage doctor --workflow scan \
  --brief ravage-brief.yaml \
  --authorized-remote-target

ravage scan ravage-brief.yaml \
  --probe surface_map \
  --authorized-remote-target \
  --report

Per un'esecuzione remota guidata da modelli:

ravage attack ravage-brief.yaml \
  --authorized-remote-target \
  --allow-paid-models \
  --report

Gli attacchi remoti autorizzati usano per impostazione predefinita la policy a basso rumore per l'intera esecuzione: solo HTTP metered nativo, pacing sub-1-RPS, un tetto fisico alle richieste, caching e deduplicazione conservativi di GET/HEAD, backoff adattivo, retry limitati e circuit breaking. Il registro durevole sopravvive alla ripresa. I dettagli sono in Architettura.

Comprendere i risultati

Ravage distingue osservazioni, risultati candidati e vulnerabilità confermate. Un flag CTF è una possibile prova, non un requisito. Su un'applicazione ordinaria, un'esecuzione può essere utile e riuscita senza trovare alcun flag; le vulnerabilità confermate vengono comunque scritte nel report.

Una volta avviata un'esecuzione di attacco, il suo artefatto canonico privato leggibile dalla macchina è RUN_DIR/report.json, incluse le esecuzioni incomplete. --report scrive anche RUN_DIR/report.md.

ravage observe RUN_DIR
ravage audit verify RUN_DIR
ravage report RUN_DIR --brief ravage-brief.yaml

Per l'HTTP strutturato catturato dal grafo dell'agente:

ravage traffic list RUN_DIR
ravage traffic show RUN_DIR REQUEST_ID

Il report include riferimenti alle evidenze, qualità della contabilità delle richieste, stato di completamento e il motivo per cui un'esecuzione incompleta si è fermata. Non trattare mai un'asserzione del modello non validata come un risultato confermato.

Funzionalità

Le skill di conoscenza possono guidare la prioritizzazione, ma non possono aggiungere strumenti, espandere lo scope o confermare risultati. Inizia con:

ravage skills list builtin
ravage skills validate builtin

L'Improvement Lab acquisisce la struttura di esecuzioni precedenti sanitizzata, valuta patch candidate in workspace indipendenti, archivia le versioni accettate e rifiutate e richiede evidenze di non-regressione corrispondenti prima della promozione. È un sidecar: non muta il checkout del sorgente né si promuove silenziosamente.

Gli artefatti orbitali e di pacchetto passivi possono essere ispezionati separatamente:

ravage satcom inspect orbit.tle --format tle --output orbit-report.json
ravage satcom inspect capture.bin \
  --format ccsds-space-packets \
  --direction auto \
  --output packet-report.json

Il supporto SATCOM è parsing e analisi passivi, non un trasmettitore radio o un sistema di controllo di veicoli spaziali.

Sviluppo

scripts/bootstrap.sh --dev
source .venv/bin/activate
python -m pytest -m "not integration" -q
python -m ruff check --select E9,F .
python scripts/qa/check_docs.py
python scripts/qa/check_release.py

I test di integrazione basati su Docker e i confronti XBEN congelati sono gate di rilascio separati. Leggi Benchmarking prima di interpretare i risultati dei casi; un flag fortunato non è evidenza di un miglioramento affidabile.

Documentazione

• Come usare Ravage
• Configurazione e risoluzione dei problemi
• Autenticazione
• Architettura
• Skill
• SATCOM passivo
• Improvement Lab
• Benchmarking
• Policy di sicurezza
• Contribuire

Usa ravage --help e ravage COMMAND --help per le opzioni esatte nel tuo checkout.

Licenza

Apache License 2.0. Vedi LICENSE, DISCLAIMER e SECURITY.md.