Exploit

V0 · check missing

1. Prepare. The tester changes the requested record from own-supplier P17 to P29. The S17 session is already valid. P29 belongs to S29, so the intended policy does not permit this read. This authorized, isolated teaching test uses synthetic records and a known valid S17 session, whose secret is never displayed. The tester knows P17 and P29 from the fixture; no identifier enumeration is shown. Both variants validate the session and identifier syntax. The intended policy is read only one’s own supplier records. This is a resource request after sign-in, not a new authentication flow. Choosing a variant changes the service-side owner check, not the requester, target, or policy.
2. Send. The browser sends its P29 read request over the assumed protected channel. PlantPlan records receipt only after arrival. The original P29 stays at the service. The moving label is a request containing the record identifier plus the established session context. The session secret is neither shown nor logged by the illustration. PlantPlan does not evaluate this request before it arrives. The synthetic record’s authoritative owner remains S29; changing a client field does not change ownership or permission.
3. Evaluate. V0 validates the session and identifier but has no object-owner permission check. It prepares P29 content for the response despite the intended S17-only scope. The browser has not received it yet. V0 is an explicitly vulnerable test variant. Its working session and format checks do not grant S17 permission to read S29’s data. The missing owner check is the weakness; using a different known record identifier is the exploit method. The handler prepares a copy of synthetic P29 under these fixture conditions. This stage is service-side processing, not completed response delivery. P29’s original remains stored at the service; no real supplier data or real-world incident is asserted.
4. Return. The service returns a P29 copy. Only after arrival does the browser show the other supplier’s test content. That completed unauthorized result demonstrates this exploit under the fixture conditions. The response delivers synthetic P29 content to a requester whose intended own-supplier policy permits only S17 records. The observable unauthorized effect occurs on response receipt. The original is retained at the service; this is copying, not moving ownership or deleting a record. This is one authorized reproduction of a fictional weak implementation, not evidence of a real attacker or compromise. The fixed-variant choice shows how enforcing the owner check changes the same request’s result.

V1 · check enforced

1. Prepare. The tester changes the requested record from own-supplier P17 to P29. The S17 session is already valid. P29 belongs to S29, so the intended policy does not permit this read. This authorized, isolated teaching test uses synthetic records and a known valid S17 session, whose secret is never displayed. The tester knows P17 and P29 from the fixture; no identifier enumeration is shown. Both variants validate the session and identifier syntax. The intended policy is read only one’s own supplier records. This is a resource request after sign-in, not a new authentication flow. Choosing a variant changes the service-side owner check, not the requester, target, or policy.
2. Send. The browser sends its P29 read request over the assumed protected channel. PlantPlan records receipt only after arrival. The original P29 stays at the service. The moving label is a request containing the record identifier plus the established session context. The session secret is neither shown nor logged by the illustration. PlantPlan does not evaluate this request before it arrives. The synthetic record’s authoritative owner remains S29; changing a client field does not change ownership or permission.
3. Evaluate. V1 validates the session and identifier, then checks the service-owned supplier association and P29 owner. S17 differs from S29: the read is refused before part content is released. The service-managed session association S17 and authoritative owner S29 are the same as in the V0 fixture. In V1 the object-level permission check enforces the intended own-supplier policy and fails for this cross-supplier target. A minimal owner lookup may occur internally, but no part content is released to the browser. The session and identifier checks remain valid; only the requested operation is refused. Independent own-record P17 reading still works, as shown in the vulnerability comparison.
4. Return. The service returns a refusal. After it arrives, the browser shows the refused read and receives no P29 content. The working session remains valid; this is an authorization result. The response contains a refusal and no part content; the original P29 remains stored and unchanged. This fixes the illustrated object-level read path without proving every other operation or deployment safe. No sign-in refusal, session revocation, or invalid identifier is invented. The comparison differs only in service implementation, and this result is the same checked behavior used in the trust-boundary illustration.

This illustrates one object-level read defect in an isolated authored fixture. It neither runs an exploit against a real service nor establishes live attack history or complete remediation coverage.

Flow references: OWASP - object references and object-level access checks · MITRE CWE-639 - authorization bypass through a user-controlled key · OWASP - validate permission on every request