เพนเทสต์ต่อเนื่องที่พิสูจน์ทุกสิ่งที่พบ
ชี้มันไปที่โดเมน 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.