PENTEST

Pentesting continuo que demuestra cada hallazgo

Apúntalo a un dominio, una API o una red interna. Trabaja como trabaja un pentester: enumerar la superficie, probar ataques, encadenar los que funcionan. Un escáner compara firmas y te entrega una cola para triar. El zorro solo reporta lo que consiguió provocar, y lo provoca dos veces: una para demostrarlo y otra después de que despliegues el arreglo.

Leer la documentación Conocer a los otros tres

La vista de evaluación.

Aquí ves todo lo que produjo una evaluación: el resumen que escribió el agente, los findings que probó y la actividad detrás de ellos. Abre el informe aquí o descárgalo en 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.