PENTEST

すべての結果を証明し続けるペネトレーションテスト

ドメイン、API、社内ネットワークのいずれかに向けてください。ペンテスターと同じ順序で動きます。面を洗い出し、攻撃を試し、通ったものをつなぐ。スキャナーはシグネチャを照合し、仕分け待ちの列を渡してきます。キツネは実際に起こせたことだけを報告し、しかも二度起こします。一度は証明のため、もう一度は修正をリリースした後です。

ドキュメントを読む他の 3 体を見る

アセスメントのビュー。

ひとつのアセスメントが生んだものがすべてここにあります。エージェントが書いた要約、証明した finding、その裏側の活動。レポートはここから開けます。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.