API Logic Flaw

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

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

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.

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.

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)

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.

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

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

• 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

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