PENTEST

Pentest continuo che dimostra ogni riscontro

Puntalo su un dominio, un’API o una rete interna. Lavora come lavora un pentester: enumerare la superficie, tentare attacchi, concatenare quelli che riescono. Uno scanner confronta firme e ti consegna una coda da smistare. La volpe riferisce solo ciò che è riuscita a provocare, e lo provoca due volte: una per dimostrarlo e una dopo che hai rilasciato la correzione.

Leggi la documentazione Conosci gli altri tre

La vista della valutazione.

Qui vedi tutto ciò che una valutazione ha prodotto: il riepilogo che l'agente ha scritto, i finding che ha dimostrato e l'attività dietro di essi. Apri il report da qui, o scaricalo in PDF.

JWT tenant isolation and admin surface validation

Completed4 days ago31 minutes

4Risks1 critical2 high1 medium

ExecutionAutomated

Started4 days ago

Duration31 minutes

Risks4

Credits180

Summary

The scope granted a standard workspace token for a non-privileged member of tenant 4821. The goal was to establish whether that token can reach data or operations belonging to another tenant.

It can. The token was accepted on a tenant-scoped query for account 4822 with no error and no audit entry, and the admin GraphQL catalogue enumerated persisted operations that a standard session should not see. Signup was then shown to trust a client-supplied tenant_id, which is how a caller reaches an arbitrary tenant in the first place.

What was refused

SQL injection against the catalogue filter was refused — the query is parameterised. A JWT alg:none downgrade was rejected by the verifier. Both are recorded because a run that lists only what worked is describing a demo rather than a target.

Recommended order

Derive tenancy server-side at signup and reject client-supplied tenant ids.
Scope the token check to the tenant on every read path, not just on writes.
Record cross-tenant reads in the audit log so the next attempt is visible.