Daily - Tanuki

Vulnerabilities Covered

IDOR (Insecure Direct Object Reference)

Summary

This challenge demonstrates an Insecure Direct Object Reference (IDOR) vulnerability in the Tanuki flashcard application's statistics API endpoint. After registering an account and being assigned a user ID, the application exposes a /api/stats/{id} endpoint that lacks proper authorization controls. By manipulating the numeric ID parameter, an attacker can access other users' statistics and sensitive data, including a hidden achievement flag. The vulnerability highlights the importance of implementing object-level access control rather than relying solely on authentication to protect user-specific resources.

Reference

Bugforge.io

Account Registration and Baseline Analysis

The first step is to register a new user account and analyze the registration request and response.

During registration, the server response reveals important information:

The API endpoint /api/register is used for account creation
The newly created user is assigned an id of 4, indicating at least 3 other users exist on the platform
No role parameter is visible in the request or response, making role manipulation unlikely for this challenge

This initial reconnaissance provides valuable context about the application’s user structure.

Registration response

Application Feature Review

After logging in, the dashboard presents several features:

A welcome message displaying the user’s name
Available study decks (e.g., “Linux Trivia”)
Navigation menu with: My Decks, Browse Decks, Stats, and Logout

Dashboard

With IDOR as the target vulnerability, the focus shifts to identifying endpoints that use predictable identifiers.

Initial Endpoint Testing (Study Decks)

Clicking “Start Studying” on a deck loads the URL /study/2. The numeric identifier is an immediate candidate for IDOR testing.

Study Endpoint

Testing revealed:

/study/1 returns a “Planets & Moons” deck
/study/2 returns the “Linux Trivia” deck
/study/3 returns another valid deck

Study Planets

Using Caido Automate to enumerate IDs 1-100 (with limit=100 parameter) identified only 3 valid decks. Filtering responses for the flag pattern bug{ yielded no results.

Secondary Endpoint Testing (Decks API)

The /decks/{id} endpoint was also identified in the HTTP traffic. Similar enumeration was performed:

Only 3 valid deck IDs were found
No flag pattern was present in any response
Testing /decks/0 and /study/0 returned no results (ruling out zero-indexed entries)

Decks Endpoint

Discovering the Hidden API Endpoint

When navigating to the Stats page, the browser URL showed a static page with no identifiable parameters. However, inspecting the HTTP traffic revealed an API call:

GET /api/stats/4

The 4 in this endpoint correlates directly to the user ID assigned during registration.

Stats Endpoint

Exploiting the IDOR Vulnerability

With the /api/stats/{id} endpoint identified, IDOR testing was straightforward. Sending the request to Caido Automate, we configured the id parameter with a numeric payload range and ran the attack. The server returned statistics for other user IDs without any authorization verification.

Stats Automate Configuration

Flag Retrieval

Running the Automate attack and analysing the results, we confirmed that data was returned for other users. The achievement_flag field was included in the response payload, completing the challenge through unauthorized access to another user’s statistics.

Impact

Unauthorized access to any user’s statistics and personal data
Exposure of sensitive achievement data and potentially other user information
Complete breakdown of horizontal access controls
Demonstrates how hidden API endpoints can expose IDOR vulnerabilities that aren’t visible in the browser URL

Vulnerability Classification

OWASP Top 10: Broken Access Control
Vulnerability Type: Insecure Direct Object Reference (IDOR)
Attack Surface: User statistics API endpoint
CWE: CWE-639 - Authorization Bypass Through User-Controlled Key

Root Cause

The /api/stats/{id} endpoint performs authentication (verifying the user is logged in) but fails to implement authorization (verifying the user has permission to access the requested resource). The application trusts the user-supplied ID parameter without validating that the authenticated user owns or has permission to view that data.

Remediation

Implement object-level authorization checks on all API endpoints that access user-specific data
Use session-based user identification rather than user-supplied IDs where possible
If user IDs must be exposed, use non-sequential UUIDs instead of predictable integers
Log and monitor for suspicious patterns of sequential ID access
Apply the principle of least privilege: users should only access their own resources by default

Key Takeaways

Always monitor HTTP traffic - API calls may not be visible in the browser URL, especially in Single Page Applications (SPAs)
Registration responses contain gold - User IDs, role assignments, and API patterns revealed during registration are invaluable for reconnaissance
Don’t stop at the first endpoint - Multiple endpoints may use identifiers, but only some may be vulnerable
Predictable IDs are a red flag - Sequential numeric identifiers (1, 2, 3, 4…) are prime candidates for IDOR testing