Caso d'uso

Ispeziona il traffico. Sappi cosa non puoi vedere.

Limita la decifrazione esattamente agli host che stai testando, esegui regole blocca/simula/elimina sul filo, e ottieni una risposta onesta su cosa il certificate pinning ti nasconde ancora.

A vertical trust stack threaded by one line: a write-only vault door with an inbound arrow and a blocked outbound arrow, an append-only audit ledger of timestamped rows, a least-privilege role matrix, and at the base a database wrapped in a row-level-security shield. write-only audit_log 12:04:31 12:04:32 12:04:40 least privilege rls

Il problema

La maggior parte degli strumenti MITM esagera quello che riescono a vedere

Uno strumento che tace sul certificate pinning spreca una sessione di ricerca su un target che non sarebbe mai riuscito a decifrare.

Per ricercatori di sicurezza e tester di app che verificano cosa un'app o un dispositivo invia davvero — SDK di terze parti, endpoint non documentati, se un'app degrada in sicurezza quando una richiesta viene bloccata o corrotta.

Busymate limita la decifrazione a un elenco SSL per dispositivo che controlli, esegue lo stesso motore di regole blocca/simula/elimina sul filo su iOS, Android e il proxy, e registra ogni azione — incluso l'accesso diretto al database — in un audit trail solo in append. Ed è onesto sull'unica cosa che non può fare: un'app con il proprio certificate pinning non verrà decifrata tramite l'elenco SSL, su nessuna piattaforma.

Come lo risolve

Decifrazione mirata, regole a livello di filo, un vero registro di audit

Ogni affermazione qui sotto è verificabile — niente qui è una scatola nera.

Blocca, simula ed elimina sul filo

Lo stesso motore di regole sandboxed gira in linea su iOS, Android e il proxy — un unico set di regole, applicato in modo identico ovunque scorra il traffico del tuo target.

Ogni azione, verificata

Un audit trail solo in append registra ogni azione su ogni superficie, incluso l'accesso diretto al database. Seguilo live, filtralo, o condividi un permalink all'evento esatto.

Onesti sul certificate pinning

Un'app che fissa il proprio certificato non verrà decifrata tramite l'elenco SSL su iOS, Android o il proxy — è un limite reale, non un bug. Per il traffico già dentro un browser Chromium, la cattura basata su CDP (bmc) lo legge dopo la decifrazione e non è influenzata dal pinning, perché non tocca mai la connessione TLS.

Superfici coinvolte
  • Proxy
  • iOS
  • Android
  • CLI
  • Security & audit

Procedura guidata

Da un host target a un risultato documentato

Con un registro reale alla fine.

  1. 01

    Delimita l'elenco SSL

    Aggiungi solo gli host che stai testando all'elenco SSL del dispositivo o del proxy, e fidati della CA generata su quel dispositivo. Tutto il resto passa intatto.

  2. 02

    Sonda con regole

    Scrivi una regola blocca, simula o elimina — o uno script JS sandboxed — per vedere come si comporta il target con una risposta corrotta, ritardata o mancante.

  3. 03

    Segui l'audit trail

    Rivedi esattamente cosa è cambiato e quando — ogni regola scattata, ogni host decifrato — come un record con permalink e solo in append che puoi allegare a un report.

Sul bersaglio

Come funziona contro un'app reale

Tre mosse, e una traccia di ciascuna.

  1. 01

    Limita la decifratura agli host che stai testando

    Sul dispositivo o sul proxy, aggiungi alla lista SSL solo gli host del bersaglio e autorizza lì l'autorità di certificazione generata. Tutto ciò che è fuori da quella lista resta cifrato end-to-end, così una sessione contro un'app non apre mai il resto del traffico del telefono.

  2. 02

    Sonda con regole e script

    Scrivi una regola di blocco, mock o scarto per un endpoint bersaglio, oppure una regola JavaScript in sandbox che riscrive una richiesta o una risposta di passaggio. Osserva come si comporta l'app quando il suo backend risponde lentamente, male o mai: il motore di regole gira in modo identico su iOS, Android e proxy.

  3. 03

    Porta la traccia con te

    Ogni regola attivata, ogni host decifrato e ogni voce ispezionata finisce nel registro di audit in sola aggiunta. Filtralo sulla sessione, apri il permalink dell'evento esatto e allegalo al report insieme all'esportazione HAR del traffico stesso.

FAQ

Prima di iniziare una sessione, le solite domande

Decifrerà un'app che fa pinning del certificato?

No. Il pinning batte la lista SSL su iOS, Android e proxy: vedi che la connessione è avvenuta, non cosa conteneva. Il traffico già dentro un browser Chromium è diverso: la cattura del browser lo legge dopo che Chrome l'ha decifrato, quindi lì il pinning non si applica.

La cattura è limitata alle app di mia proprietà?

Gli strumenti funzionano su qualsiasi traffico raggiunga il dispositivo o il proxy, e i termini richiedono che l'app sia tua o che tu sia autorizzato a testarla. La cattura è opt-in su ogni piattaforma e può essere fermata e rimossa in qualsiasi momento.

Dove finiscono i dati catturati?

La decifratura avviene sul dispositivo o sul tuo proxy. Le voci che scegli di sincronizzare restano nel tuo account per la finestra di conservazione valida su tutta la piattaforma e puoi eliminarle quando vuoi; nei corpi possono comparire token e credenziali, quindi tieni stretta la lista SSL.

Posso dimostrare cosa ho fatto durante una sessione?

Sì. Il registro di audit è in sola aggiunta e annota ogni azione su ogni superficie: dashboard, API e agenti IA allo stesso modo. Ogni evento ha un permalink, così una scoperta può citare il momento esatto in cui una regola è stata applicata.

Verificalo tu stesso — non fidarti solo della nostra parola

Il modello di sicurezza è una pagina, non un'affermazione — leggi esattamente cosa viene applicato e dove.

Ask your mate