PENTEST

Непрерывный пентест, который доказывает каждый результат

Направьте её на домен, API или внутреннюю сеть. Она работает так, как работает пентестер: перечислить поверхность, пробовать атаки, связывать те, что проходят. Сканер сверяет сигнатуры и отдаёт вам очередь на разбор. Лиса сообщает только о том, что ей действительно удалось сделать, — и делает это дважды: один раз как доказательство и один раз после того, как вы выкатили исправление.

Читать документацию Познакомиться с остальными тремя

Экран оценки.

Здесь всё, что дала одна оценка: сводка, которую написал агент, доказанные находки и активность за ними. Отчёт вы открываете отсюда или скачиваете в 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.