اختبار اختراق مستمر يثبت كل نتيجة
وجّهه إلى نطاق أو واجهة API أو شبكة داخلية. يعمل كما يعمل مختبِر الاختراق: حصر السطح، تجربة الهجمات، ثم تسلسل ما ينجح منها. الماسح يطابق البصمات ويسلّمك طابورًا لتفرزه. أما الثعلب فلا يبلّغ إلا بما استطاع إحداثه فعلًا — ويُحدثه مرتين: مرة للإثبات، ومرة بعد أن تطلق الإصلاح.
واجهة التقييم.
هنا كل ما أنتجه تقييم واحد: الملخّص الذي كتبه الوكيل، والنتائج التي أثبتها، والنشاط وراءها. افتح التقرير من هنا، أو حمّله بصيغة PDF.
JWT tenant isolation and admin surface validation
Completed4 days ago31 minutes
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.