Daily - Copy Pasta

Vulnerabilities Covered

Broken Access Control IDOR (Insecure Direct Object Reference)

Summary

This issue is a broken access control flaw in the collection sharing functionality. When a public collection is shared, the application returns the contents of every snippet assigned to that collection without re-validating each snippet's individual visibility setting. By creating a public collection, assigning a private snippet to it, and sharing the collection, the private snippet's data is exposed through the public share response. This allows an attacker to bypass per-object access controls and read sensitive data, including the challenge flag, demonstrating an insecure direct object reference (IDOR) where the trust boundary is enforced at the collection level rather than on each underlying snippet.

Reference

Bugforge.io

Account Creation and Private Snippet

A new user account was registered to establish a baseline within the application. Once authenticated, a snippet was created with its visibility set to private. This served as the controlled target object for later testing, allowing any unauthorized exposure of its contents to be clearly attributed to a broken access control flaw rather than intended behavior.

Private snippet creation

Creating a Public Collection

Testing then moved to the collection functionality. A new collection was created with its visibility set to public. Collections act as containers that group multiple snippets together and can be shared via a dedicated endpoint, making them a useful surface for testing how access control is enforced across grouped objects.

Public collection creation

The public collection was shared while intercepting the request and response. At this stage no snippets had been assigned to the collection, and the share endpoint returned an empty snippets array. This established a baseline for the share response and confirmed how the endpoint exposes collection contents before any snippet was associated with it.

Assigning the Private Snippet and Extracting the Flag

The previously created private snippet was then assigned to the public collection. The collection was shared again, and the response now included the contents of the private snippet, with no per-snippet authorization check being performed. The challenge flag was present in the share response, confirming that private data could be exposed simply by associating it with a public collection.

Assign private snippet to collection

Impact

Disclosure of private snippet contents through public collection sharing
Bypass of per-object visibility and access control settings
Exposure of sensitive application data, including the challenge flag
Erosion of the trust boundary between private and public objects

Vulnerability Classification

OWASP Top 10: Broken Access Control
Vulnerability Type: Insecure Direct Object Reference (IDOR)
Attack Surface: Collection sharing and snippet assignment endpoints
CWE: CWE-639 - Authorization Bypass Through User-Controlled Key

Root Cause

The application enforced visibility checks at the collection level only. When a collection was shared, the backend returned the contents of all assigned snippets without re-validating each snippet’s own visibility setting. As a result, a private snippet inherited the public exposure of any collection it was added to, allowing access control to be bypassed.

Remediation

Enforce visibility and authorization checks on every snippet returned, independent of the parent collection
Prevent private snippets from being assigned to public collections, or strip private items from public share responses
Apply the most restrictive visibility setting when objects of differing visibility are combined
Implement centralized access control logic and perform regular authorization testing on grouped or nested objects
Add logging and monitoring for sharing actions that mix private and public content