Avatar

Labs / API Logic Flaw

  • Daily Challenge
  • Released 21 Jul 2025
The lab needs to be started first.
Need help to start?
Daily Challenge

API Logic Flaw - Complete Solution Walkthrough

Understanding the API Architecture

This API implements a simple authentication system with a critical logic flaw. Let's understand how it works:

  • User Database: The API maintains a simple array of users with credentials and roles
  • Session Management: Uses in-memory session storage (in production, this would be Redis/database)
  • Authentication Flow: Multiple authentication methods are checked in sequence
  • Authorization: Role-based access control for different endpoints

Step 1: API Reconnaissance

  1. Start by accessing the API status endpoint: GET /api/status
  2. This reveals all available endpoints and their purposes
  3. Note that /api/profile requires authentication and /api/admin requires admin privileges
  4. Try accessing these endpoints directly to understand the authentication requirements

Step 2: Understanding the Authentication System

The API uses a multi-layered authentication approach:

  1. Session Cookie Authentication: Checks for session_id cookie
  2. Bearer Token Authentication: Checks for Authorization: Bearer <token> header
  3. Parameter-based Authentication: Checks for user_id parameter in GET/POST requests

Key Insight: The authentication checks are performed in sequence, and if any method succeeds, the user is considered authenticated. This creates a logic flaw.

Step 3: Analyzing the Logic Flaw

The vulnerability exists in the isAuthenticated() function. Here's the problematic logic:

// LOGIC FLAW: Check for user_id parameter in GET/POST
if (isset($_GET['user_id']) || isset($_POST['user_id'])) {
$userId = $_GET['user_id'] ?? $_POST['user_id'];

// Find user by user_id
foreach ($users as $username => $userData) {
if ($userData['user_id'] == $userId) {
return [/* user data */];
}
}
}

The Problem: This code allows direct authentication by simply providing a user_id parameter, bypassing all other security checks.

Step 4: Discovering User IDs

  1. Login with the provided credentials: POST /api/login with {"username": "test", "password": "test"}
  2. This will return user information including the user_id
  3. From the response, you'll see that the test user has user_id: 23
  4. You can also try the admin credentials to discover the admin user_id

User Mapping:

  • Username: admin → user_id: 1 (admin role)
  • Username: test → user_id: 23 (user role)

Step 5: Exploiting the Logic Flaw

Now that we understand the vulnerability, we can exploit it:

  1. Access Admin Panel: Send request to GET /api/admin?user_id=1
  2. Access User Profile: Send request to GET /api/profile?user_id=23
  3. POST Method: You can also use POST /api/admin with body {"user_id": 1}

Why This Works: The API checks for the user_id parameter first, and if found, it directly authenticates the user without checking session tokens or other security measures.

Step 6: Extracting the Flag

  1. The successful request to GET /api/admin?user_id=1 will return:
  2. {"message": "Admin panel accessed successfully", "admin_data": {"system_status": "operational", "active_users": 42, "server_uptime": "7 days", "flag": "2915b155-bfde-4532-897f-ebdf8ed52d82"}}
  3. The flag is: 2915b155-bfde-4532-897f-ebdf8ed52d82

Step 7: Understanding the Root Cause

This vulnerability exists because:

  • Poor Authentication Design: The API allows multiple authentication methods without proper validation
  • Parameter Trust: The code trusts user-provided parameters without verification
  • Missing Authorization: No checks to ensure the user_id parameter is legitimate
  • Insecure Default Behavior: The authentication function prioritizes convenience over security

Security Implications and Best Practices

  • Authentication Bypass: Logic flaws in authentication can completely compromise application security
  • Parameter Validation: All user inputs must be validated, sanitized, and verified
  • Session Management: Use secure session tokens with proper expiration and validation
  • Authorization Checks: Implement proper role-based access control with server-side validation
  • API Security: APIs must implement proper authentication and authorization checks
  • Code Review: Regular security audits can catch logic flaws before deployment
  • Defense in Depth: Multiple layers of security help prevent single point failures
  • Real-world Impact: Such vulnerabilities are commonly found in production APIs and can lead to data breaches

Testing Methodology

When testing APIs for similar vulnerabilities:

  1. Map the API: Discover all endpoints and understand their purposes
  2. Analyze Authentication: Understand how authentication is implemented
  3. Test Parameters: Try manipulating various parameters to find bypasses
  4. Check Authorization: Verify if role-based access is properly enforced
  5. Document Findings: Record all discovered vulnerabilities and their impact